Your Competition is Already Using AI w/ Mike Gibson | Episode 202

Speaker A: With the AI, the whole thing, like when behind our backs, it's just compressing all that. And those that stay on top of the wave are going to be very, very successful, whether it be monetary, they're going to be challenged, they're going to grow their careers. Those that aren't on top of the wave, they're going to be crushed by the wave. And that's what we tell our team, right? AI is not going away. But if you get on top of that wave versus underneath the wave, you're much better persistent.

Speaker B: Welcome to Software Leaders Uncensored. I'm Steve Taplin and every episode I get to sit down with technology and engineering leaders to really hone in on um, what's working, what's breaking and how growing, scaling companies are dealing with today's tech challenges. And after over 200 of these conversations, we see patterns keep forming. In fact, we just released our first research report called why Software Projects Fail. And it was based on the first 195 episodes of this podcast. And that's really what this show is about, is analyzing patterns so we can all learn and keep moving forward, working through challenges. Today I have Mike Gibson, CTO at Planet dds, here to talk about their unique solution they have for the dental industry and how they're dealing with the engineering challenges, cross team dependencies and deployment pipeline gaps. Uh, Mike, welcome.

Speaker A: Thank you. Thanks for having me.

Speaker B: You bet. If you would tell our listeners a little bit, uh, about Planet dds.

Speaker A: Yeah, so Planet DDS is a, as you mentioned, dental technology companies really you look at as a CRM or ERP of a complete dental organization, not necessarily like a small one provider location, but these are like enterprises. These are corporations that have 10, 100, even a thousand locations. So there's definitely a need to provide enterprise solutions in this space which um, is not always intuitive when you think about dental. But there is definitely an enterprise play and it's all about how can we aggregate data, roll up things like rc, collection, um, of money, working with insurance companies and so forth. How do we improve the patient experience? So there's a lot to, a lot more than I initially thought when I joined this um, space. There's a lot of complexity and importance around delivering mission critical software to dental organizations.

Speaker B: So educate me on the landscape across the US Are ah, there like what percent of dental offices are like individually owned where they only maybe have one or two offices? Is that a big part of the segment?

Speaker A: It is a big, it's still a large component of the segment is the individual dentists that might have one or two locations. Right. And what happens is, you know, you go in dental school, you learn to serve patients, they get into practice and running a business is different than serving patients. Right. So some dentists decide they want to roll it up and sell it to what they call it a dso, Dental service organization, corporation side of things or others get close to retirement and they want to sell off. So there's definitely a trend towards more of going to the enterprise space but I don't have the exact percentage. But it's still in the minority. I would say less than 20% are part of any type of DSO or type of larger roll up.

Speaker B: Okay, awesome. And you know your company is private equity backed. You guys have made great headway in the market. Tell us about your product and engineering organization, how many people you have, where they sit, how you like to manage it.

Speaker A: Yeah, so all great questions of course. So just a little bit of context to pioneer cloud native. So in terms of you think about the dental space, you think about medical in general, customers move slowly, right. Because of HIPAA and many different data privacy, data protection kind of concerns. So still a large percentage of the dental offices have an on um, premise solution. Right. We call these PMSS practice management solutions. We were early on go back 20 years to a uh, cloud solution right back when it was a private data center. Now we're multiple cloud providers, aws, Azure, GCP for example. So our niche is really helping these dental practice whether if you're small or larger do this transformation into the cloud, which still happens believe it or not.

Speaker B: So and uh, there's no reason why companies shouldn't at this point.

Speaker A: There's, there's no reason we can offer better security, data aggregation, better solutions. Right. Time to market like everything that the cloud provides in terms of solutions, SaaS provides. Our ability to add in Gen X AI solutions is much more quick. Our innovation pace is much quicker than on prem. But there's still that legacy mindset in um, some, in some of the dental area. It's like they're all in all industries. So in terms of our footprint, you know we're, we grew over time organically through our main platform called Denicon, but also through acquisitions. We've acquired two or three companies and platforms more than that. But in terms of the kind of the big pieces of the puzzle. So because of that I have, so as a cto I have both internal and external facing technology responsibilities. So I have developers, testers, right? Product owners, architects, platform engineering, site reliability engineering, corporate it. So spread out all across the globe. Uh primarily our customer base is 98% US based. So um, we do need an on prem shore in US based presence for production support so forth. So I do have about half of my full uh time employees. Engineering, engineering staff is in the US and that's comprise about 50 in the US. I have another 30 to 40 as you say by go back at 6070 in the US about 30 to 40 in the UK at this point. That's, that's our full time um, footprint and then we also work with offshore partners and we have another depends on the project and time of the time of year honestly another 60 or so contractor. So altogether about 160 heads.

Speaker B: All right, uh, you know you're in the U.S. how do you and your team manage the time zone differences to make sure you can collaborate and be productive with your, your team? That's offshore.

Speaker A: Yeah, you know, kind of the age long challenge. A lot easier now with tools like Zoom and just the modern technologies using AI agents in terms of note taking so forth. We really try to be thoughtful in our meeting schedules. The dirty truth is yes, we're extended. I was on call this morning at 6:30am, uh my time opening a call tonight at 10:00 o', clock, not throughout the whole day but it does require flexibility working across time zones. But we do leverage technology and we were very thoughtful on who should be in a meeting, what time of day should that meeting be. We take turns. So just because I might be CTO does not mean I don't wake up early, have a call with a developer, Offshore for example. So we're very thoughtful about it.

Speaker B: Gotcha. Have you seen, you know certainly, uh, I can speak to US based developers, my company sonatafy Technology, we have both us and Latam based or nearshore developers and we've seen you know, phenomenal adoption with AI tooling from uh, an entire software development lifecycle perspective to make the process more efficient. I've gotten various opinions from other tech leaders as have if offshore teams have had the same acceleration in use of those tools. Would love to get your take.

Speaker A: Yeah, I think great question. I would say they have not from what we've seen. I think in general uh, general Brush, there's always exceptions. Right. But general Brush, an offshore team is very good at doing tasks. So you need to feed them the tasks, you need to feed them the designs. They're not always as innovative as you know, onshore full time employee. So with the rapid evolution of AI we are looking at to reduce our footprint offshore repurpose those dollars, not necessarily the headcount equivalency, but the dollars into onshore resources. A little higher level, it can be a little bit quicker and innovate and um, using tools like cloud code and so forth. Gotcha. I think over time, at least for us and our experiences and our needs will be less offshore and more onshore.

Speaker B: So you, you as a company, you've had your maiden platform, you have, your company has done acquisitions. First thing that, that flashes my mind is tech debt and how you guys are attacking that. As you know a guy who's uh, acquired 11 companies throughout my career, you're, that's, that can always big challenge. How are you attacking that 100%.

Speaker A: So it is a challenge. Um, it's a challenge even without applications. Right. As you move fast, I mean you throw in potential AI slap on top of that. So we're again we're thoughtful on how we allocate our resources so we do a percentage of, so whether we do a scrum team or a pod, percentage of that team is allocated towards either tech investment, CS being like defects, customer support activities could be internal as well and product enhancements. So if we don't allocate enough time for tech investment, it just builds. Right. But, and, and everyone has different perspectives and different needs in the business. So again we're very thoughtful going into each quarter saying that we'll allocate X percent of tech, uh, investment per platform.

Speaker B: Gotcha.

Speaker A: Then within that. Sorry, within that, then it's up to technology leaders to allocate that, that capacity to the most critical, whether it be security compliance, refactoring, tech debt reduction type of activities.

Speaker B: Gotcha. So what's your backlog look like today? And how, how often do you have to take a fresh look at that and say why the hell is there so much stuff in here?

Speaker A: It's big, I'm not going to lie. It's large. Right. Especially as you uh, as these platforms age out and you like to think everything is going to be in services, whether it be microservices or even just smaller services, but we're still dealing with monolithic components of our platforms. And not only that is we're also trying to integrate our platforms more tightly together. Right. Not only from a user experience, but from a back end data exchange. So there is a lot of focus on that side of things. And as we build more and more and we innovate more, it just creates more of a backlog. Whether it be, you know, you do something as an mvp, right. You try to get something out quickly and you have good intentions to go back to round it out, Whether it be additional enhancements or we fixed some, you took some shortcuts along the way, so you have good intentions. That's tough to do now, I think looking forward and even in the present day, we can really take advantage of AI to help us with that.

Speaker B: Gotcha. Now, before the show, you were telling me how you have been reorganizing your teams from Scrum teams to pods. And I'm a big believer of this as well. Would love to hear your thought process on what's led to that and what's been the good, bad and ugly with that.

Speaker A: Yeah, I know, uh, it's exciting, right? So I'm old enough to remember waterfall before Scrum, right? And then we turn into Scrum teams where, again, it varies, but you might have five developers, you might have two testers, you have some level or layers of different management like product ownership, product management, engineering leaders and so forth. Right? And with good intentions, you think you can move faster with that. At some point it becomes even heavier processed. I use analogy of taking medication, right? If I have a headache, I might take two Advils. If I take the whole bottle, I got a different problem, right? So it's, how do you apply the right amount of process? So what we're finding is pods is, is a, is a concept where, uh, obviously we didn't invent that, but for us that means we have a designer, right? UX designer. We have a product person and we have one, two, two or three, depending, um, on the size of the pod engineers. They work very closely together, so the advantages are smaller, so they can be more focused. So rather than having one Scrum team doing four things in parallel, you have one pod, ideally doing one thing like, so less context switching, you are closer to the, to the customer. So we require our pods to speak to an actual customer once a week or, uh, sometimes it's twice a week and on the initiative. So you get the voice of the customer quicker. You're able to move everything to the left in terms of requirement, gathering, pivoting, so forth. So by any time you do move into an Alpha or Beta or general lease, you're much closer to what it needs to be. So the pods allow us to organize ourselves smaller, do more things in parallel, but within a pod, be more focused. So to us, it's, uh, been great. It's very exciting.

Speaker B: I love it. And as I've now had over 200 conversations with smart guys like you dealing with these Challenges. Me and my cto, Chris Horvat actually wrote this book earlier this year called the Backlog Illusion and how managed pods are one of the best solutions to work through it. And you know, having that accountability of the pod, the owner on a set scope of work. We, I couldn't agree more. I felt like you just plugged my book because.

Speaker A: So I can jump in. So we actually have, let's say we have 30 pods for Q3 coming up. We'll have like six or seven pods a decade just, just to tech investment. Right. So some of us have cost optimization initiatives, but some are very focused on refactoring tech debt. Without that focus, um, a POD focus on tech investment is so easy for all of us, including myself as a CTO to slide tech investment behind. We'll do it next week, we'll do it next month right behind this new feature. But with the pause, ah, structure. It does allow from a structure perspective to really focus on tech investment.

Speaker B: I love it. I love it. Have you, you know, being in the dental space, you're dealing EMRs, you're dealing with HIPAA, uh, information. And you know, with that comes a lot of compliance and regulatory work. And we have seen a lot of clients like to have their engineers focused on the investment and the growth and the revenue generating stuff. And we'll come to companies like ours to have a focus pod around backlog on compliance and regulations. Have you got. Love to hear your thoughts.

Speaker A: Yeah. And so for us compliance is table stakes. Right. Uh, and it's, it's one of the challenges honestly we have at pods is now we have 30 teams working in parallel versus maybe let's say 10 teams. Right. Just for sake of discussion is to make sure we don't skip the compliance, the security side of things. So the coordination of that is critical within the, as I mentioned within the tech investment pods they do have the um, the mission, right. To make sure that the compliance items are taken care of. Our backlog of compliance items. We also, just because you're a pod and there's some autonomy being a POD doesn't neglect the fact that we still need to have our compliance group to be involved in all the like not so much the PRDs as we did the proper requirement documents like now we're going to more like intent canvases like trying to meet thinner with that as well. But we can't wait till the very end in our space.

Speaker B: Right.

Speaker A: For the compliance office say we have a problem. Right. So it's, it's um, more challenging and that's one of the challenges of pods. It's not only compliance side of things, but also the release management side of things. But it's something that we, as a medical provider technology solution, we cannot, um, you know, neglect by any means.

Speaker B: Gotcha. Um, makes sense now. You know, talking about your specific sector and you guys have to use your words, say an advanced CRM ERP system for dentist office. And uh, when we were talking before the show, you were telling me a lot of the users of your software are, you know, the person sitting at the front desk at the office or at the dental office, or maybe even the person in the back that might be dealing with billing and not so much dealing with patients. And I'm just going to say, from my experience, those aren't always the most technical savvy people. Tell me how, how you work through those challenges with all the great features you could bring to bear, but making sure it's tailored to your audience.

Speaker A: Yeah, no, that's a great question because you're right, I mean that the spectrum of technical users is wide, right? We sell to CTOs, right? And they have, they care about security, you know, MFA SSO type things and we sell to revenue cycle management people and they care about that. That's much more complex. And then you have a clinical, the dentist, right, they have a different perspective on this solution. And I'll be honest, it's challenging to keep all the different stakeholders happy, right, in terms of what we focus on. So in terms of we have different product managers that focus on the different areas that, that's one, one solution to our challenges. And also what we've been honestly not as well as we could have been in the past. We added quite us, uh, designers to our mix. So within our product group we have a whole group of designers and they really are focused on that user experience like reducing number of clicks. So the front, the front desk person, they don't want to click around too much, right? They want to stay in a single pane of glass and they want to be able to navigate within their space. Somebody on the back end might have different third party that they need to work into. So we're moving from a practice management solution ourselves into more of an enterprise play where not only can we provide that single pane glass of our own software, but also for the, our uh, partners. So again, different Personas. So again, how do we solve that user experience? We have customer advisory boards, lots of discussions to make sure we're trying to target the right features for the right set of stakeholders.

Speaker B: And so before the show, you described yourself as a true engineer at heart. And I know you've had past CTO roles, but you started with planning at DDS as SVP of engineering and then moved to the CTO role. What, how would you say for others who um, are, uh, make that transition? What advice would you have for them? Uh, because a lot, uh, some different skill sets there.

Speaker A: Different skill sets for sure. Uh, and I think as a cto, right, you have responsibilities beyond just the technology side of things. Right. So you have a seated table with business decisions and whether it be marketing or sales or customer support. So you definitely have to open your mind up beyond just yourself. You have to advocate for your team. You have a drive that, you know, uh, what the process is, the people, technology, all that stuff for your team. You have wider, um, responsibilities. You also need to be close to the customer. Right. Uh, whether it be pre sales, others during a project, post sales. Because really is your ability to lead your team is going to be much more effective if you have that voice of that customer. So if you're focused on technology only and you're not getting outside that box, it becomes more challenging as you step into a CTO position where you do have a wider audience and additional stakeholders.

Speaker B: Gotcha. So, you know, I know you've done that in the past and I think that's kind of the. When I look at the journey of a great smart software or product engineer and they work their way up and they're leading product and engineering teams, very technical. And then to go to the CTO side, it's almost like, uh, you're becoming a politician. You have to have that base, but you're dealing with lots of things, including non technical, high level stakeholders that say, hey, my buddy's company just slashed 60% of costs with AI. Why aren't we.

Speaker A: Yeah, I get those questions all the time. Yeah, so I spent a lot more time in PowerPoint, Excel or not really cloud, it does it for me than I do in code for sure. So it's definitely. And as the companies grow, as you mentioned earlier, we're a private equity sponsor, we have board meetings. So it's, it's really. I view myself as a translator. And you know, everybody has a different journey to get to where they are. Right. And I bounce around from developing. I did product management, I've loved PMOs, I've done support organizations, all within software. Right. But I've kind of bounced around not saying that's the best journey or the best path, but what it has Provided me is the ability to translate. I think business requirements translate. Like I've been on those calls with clients are upset. Right. I've been on um, design discussions where you have a trade off functionality versus maybe architectural decision making. So I think the CTO again, how do you get to that spot? Congratulations. But it really is the translator. And to make sure that the architect is not always win those conversations. Unfortunately, sometimes you have to bend to the business. You can't always not. You can't always prevent context switching. Right. You have to weave in. You can't always plan everything right. And as a cto as it, whether it be VP of engineering or software development manager, you're much more focused like, well, I need to finish this task and I can't be interrupted. But the problem is when you get more of a breadth of responsibilities, you have to be able to navigate that. So I would say that's a challenge that not all technologists have, but it's definitely still that they will need to charcoal.

Speaker B: Uh, I like it. So as your company continues to grow, as they make more acquisitions, what's becoming harder and harder as you grow? And as we look at the changing landscape and environment, the rapidly changing technical landscape and environment, what's become harder?

Speaker A: You know, I think I mentioned a couple ways. So in terms of like acquisitions, I think it's always challenging to. It's easy to acquire something, it's not always easy to grow value, right. And you gotta be thoughtful and you can't just, you know, spray and pray your process on a new organization, new team, right? Like this is how we do. We know best is how we grow. So there's negotiations and there's that you want to make that experience as beneficial to the business, obviously, but also to people you acquire. So as you grow, that's challenging. Then you throw an AI on top of this, right? Even I conversation this morning, even AI three months ago, over six months versus a year ago. It's just moving so fast. So what I've seen is the change management process has been super compressed, right? Where in the past you might have a project charter, whether for acquisition or big project, you go through all these gates and you have all these whiteboard discussions, I'm sitting in rooms, right, with sticky notes all over the place. All that gets compressed now with AI tools and the expectations of innovation. So I don't know if growing it's like the same problems. It's just how you scale it out and how you allocate your focus and your resources on it. It's fun to me. It's like you have this puzzle, right? And whether it be an acquisition or new technology or a new platform you're building is how's that piece fit into the puzzle for the greater good of building that puzzle out. So to me is exciting to grow, but definitely, uh, creates challenges. And then yes, and we have our CEOs or the board members. LinkedIn is our friend and sometimes our enemy as a CTO because it's just like social media. You only see the good stuff on, for the most part on LinkedIn, right? All the success stories by cutting, um, headcount and being 4x5x more productive. But you don't hear about the scar tissue that's been built up or some of the challenges around that, or the stability of the platforms that take a hit or the quality or so forth. So it's challenging, but it's exciting.

Speaker B: Well, and I like your attitude around challenges and it never cease to amaze me, but I've always believed the more challenges you could solve, the more money you can make. And you look at, you know, different team members, different employees, friends, family, when they complain about their job and they don't like stress and they don't want problems, but they want more money. As a CEO, I'm always like, I'm always trying to educate them that, you know, people in my organization or anyone I know, the ones who can solve more challenges than everyone else are the ones that make the most money, the ones that, uh, want to avoid conflict, avoid challenges. There's still a place, but you're not going to make as much. And they're like, oh, that kind of sucks.

Speaker A: Um, but completely true, though. Completely true. And again, with the AI, the whole thing, like when behind our backs, it's just compressing all that. And those that stay on top of the wave are going to be very, very successful. Whether it be monetary, they're going to be challenged, they're going to grow their careers. Those that aren't on top of the wave, they're going to be crushed by the wave. And that's what we tell our team, right, is whether you're here, there or anywhere, AI is not going away, right? If you're not embracing it, if you're not learning how to, if you think you're going to be the same place you were two years ago as you are two years now in terms of being developer, you're not understanding, you're not having clarity on what's happening. So my job, right, you didn't ask this question, but My job is to make them successful, not vice versa. But uh, they have to, they have to understand that change is faster. Pace M. Is this scary? It can be scary, right? But if you can talk about wave versus underneath the wave, you're a much better position.

Speaker B: No doubt. What are, what are some things that are slowing your engineering or product team right now? And what have you tried that's worked and not worked?

Speaker A: You know, in the, in the past I think the engineer was the developer was the maybe constraint in the system. We're finding now that with, with AI automation for co generation so forth, it's become more like on the front end things like the designer, the UX designers and then also on the back end in terms of more platform engineering ability to deploy software, scrum teams. Right. Two week sprints, kind of the goal was always to release every two weeks. Going to pods where one week sprints, how do we release quicker? But then you also have a saturation problem with our clients because they're used to having a process where we release into a staging environment so they can take a look at it and then goes into production. So I just like there's always you familiar with the theory constraints, right? There's always a constraint somewhere in the system, right. Whether it be manufacturing or software development. I think in the past, again from my experience, software development was kind of that main constraint. Now we're seeing on both ends of it. So it's how we work through that. How are we doing that? Like I mentioned before, we, we added more designers and we're really, we're adding more platform engineers to try and push more automation on that side of things so that we can continue to increase our velocity of going to market. But again, holding stability, security, fault tolerancy, all that stuff, uh, to the same standards.

Speaker B: Isn't it funny? And you know, engineers get a pat on the back for the first time. When you look at the whole software development life cycle, uh, historically it's always complaining that the engineers aren't moving fast enough. They're not doing, you know, and everybody likes to point the finger. And it's kind of funny because my company sonatafy Technology, we're brought in all the time tell us why our roadmap never seems to move and why we're not getting stuff done. And they always assume it's the engineering team. And I would say 9 and a half to 10 times over the past 12 plus months we've seen it's actually the engineers have embraced AI and coding tools and gotten more productive. And as you said the product side hasn't adopted AI like other areas. And then you have the backend testing and deployment side. But it's interesting how uh, for, for once engineers aren't being blamed. That's a big kudos for all the engineers out there.

Speaker A: Well, we're so blamed. But, and I didn't mean to imply our product group isn't AI forward thinking. I think it's just the volume is now we need to increase like the designs, they're actually very AI forward and our back end is not AI forward. But it just. As you produce more from the engineer, it just requires more from both ends. But yes, I think engineers will always be blamed honestly because it's kind of like we're at the end of the train, right? And then, and there's always the challenges of, and I live in a glass house. Like we can completely be better at optimization and better quality. All these things are better. But we are at the end of the train. We're like that last car at times if you look at the whole business cycle. So it's natural to be blamed as engineers. I think we wear that with pride.

Speaker B: Or uh, engineers are used to it,

Speaker A: we're used to it.

Speaker B: Are, are there areas where your product and engineering team has some friction?

Speaker A: I think it's healthy friction. I think healthy friction is, is healthy. Right. By definition. I think, I think they always want us to move faster and we always want to be more. I don't want to say thoughtful because that's the wrong way to say it, but more I guess diligent. So I think they make us better and we make them better. I think the classic iron, sharply iron. But we uh, have very strong product leadership. We're fortunate in our organization and it's a good challenge. Is it always, is it always easy conversations? No, but again we have, it's always good intent and we're on the same mission together, the same journey. So uh, again we embrace the opportunities to get better within engineering, but it's not always our fault. To your point.

Speaker B: So a common challenge that I have a lot of techno tech leaders talk about is uh, this hot topic of the thought to, to build faster, to have better engineering velocity. It's about adding more people, more teams, more engineers and oftentimes leaders get frustrated that it's not a necessarily a one to one of uh, okay, I can just add 10 more engineers and our productivity will go up. Uh, X. What's, what's your take on that?

Speaker A: Yeah, I think it's. I'm in the School of it's not like just producing more but it's producing the right things. Right. And I think the AI tooling helps with that all the way from the again the design phases, getting customers involved, prototypes, that's always been possible but it's so much easier now than it's been in the past.

Speaker B: I think that's one of the most amazing things. There's no more months and hundreds of thousand dollars to create a good prototype or MVP now. It's, it could be done in you know, hours or days.

Speaker A: We've released products in three weeks. That would taken us uh. And again these aren't like massive platforms, right. But these are like patient facing applications and even dentist facing applications in like three to four weeks. And that wouldn't taken us three, four months. Best case in the past. Right. So and all that is because of the upfront side of things and obviously

Speaker B: the cogeneration, you know, as uh, common challenge is, you know, it's, it's not more people, whether it's an engineering or product or platform doesn't always equate to more productivity.

Speaker A: Yeah, no, I agree and I, I've never been a, what they call like a kingdom builder. Right. I accept the fact that it's better for the business to do less with more. Right. And that includes headcount. So again it's, it's the and dollars. Right. We also have to consider the other side is our customer's ability to, in our market's ability to consume that pace of innovation and velocity of new features. But as, and as you mentioned earlier about difference between like a VP versus cto, a VP might, and maybe it's not kingdom building, but they might be more focused on. Well we need more people. Right. Whereas an executive at like a C level is much more focused on not only top line but also bottom line. So how can we become more efficient? How can we do more with less or how can we do. Maybe the question is how can we do more with the same. Right. And that's what we're finding again through the pods and that's again building the right things quicker. I think it's a huge benefit of the pods but also not looking to stack up more bodies just because we can do more. Again, being thoughtful in what we do with the world math.

Speaker B: Mike, last question for you. What's one piece of advice you'd give to other engineering leaders who want to rise to the CTO level with growing private equity backed companies? What kind of advice would you have?

Speaker A: Yeah, I think it's uh, you know, embrace change. Right? Private equity is different than large corporations. I've been small, I've been startups, I've been private equity back for years. I've been, you know, publicly traded companies. Same, same challenges, but there are different pressure points. Right? So private equity in particular, um, you know, embrace, embrace the challenge of growing both your top line and your property at the same time, right? It's, it's challenging, but embrace that. Embrace change, embrace acquisitions. Embrace being, you know, curious on things and whether it be private equity or any kind of, you know, finance back, um, company, just remain curious and, and really put yourselves in. And this might sound so simple, but it's, I don't see it always. Right. Put yourself in someone else's shoes, I should say. See how their days think through their, their experiences. Be empathetic to uh, your customers, be empathetic to your internal stakeholders to really understand like how can I, as an owner of a group, how can I deliver better for the greater good? So again, it's a little bit being less selfish, if you will, and being more empathetic to all the areas and private equity just intensifies that. But I love it. It's challenging. It's a great space to be in.

Speaker B: Awesome. Mike, thank you for getting uncensored with us today. Sharing insights of, uh, how you approach the CTO role and how you've attacked the challenges. It's been awesome. Thank you.

Speaker A: Appreciate your time.

Speaker B: That's it for this episode of Software Leaders Uncensored. If you're leading a tech or engineering organization and any of these patterns sound familiar, make sure to hit subscribe. Also get a copy of our why Software Projects Fail report. I'm Steve Tatlin.

Speaker A: See you next time.

Speaker B: That's a wrap. Another great episode of Software Leaders Uncensored. Thank you guys so much for listening. I really appreciate it. It's a lot of fun doing this show. I love talking with great tech leaders. As a side note, if you're interested, check out my new book, Fail Hard, Win big. This is the story of how I built 30 companies, failed on 20 and turn 10 into multi million dollar wins. The common thread with all of them was custom software. Also, if you need software development help out there, my company, Sanotify Technology, we deliver world class software development engineers out of Latin America. We have a solid track record of helping companies launch better products and faster. Thanks again for listening. Appreciate it and appreciate you.