#393 Gen AI and Technical Due Diligence: Matt Van Itallie on Navigating Software Acquisition Risks

[00:00:00]

Mehmet: Hello and welcome back to a new episode of the CTO Show with Mehmet. Today, I'm very pleased joining me, Matt van Itallie. Matt, thank you very much. It's so early for you over there in the East Coast of the United States. So thank you for [00:01:00] making the time. The way I love to do it is, you I'd like my guests to introduce themselves, tell us a little bit more about their journey, you know, and what you are currently up to.

Mehmet: So the floor is yours, Matt.

Matt: Mehmet, thank you so much. And this is absolutely worth, uh, getting up early to talk to you. I'm honored, honored to do it. So of course, I'm Matt Van Itallie, uh, grew up in upstate New York. I'm the son of a math teacher. And a computer programmer. I say that because what SEMA has done with our business is treat code as data.

Matt: So I wonder if it was in the water for me to ultimately have this job, although it's been quite quite a path to get here. I was a. Coder early, you know, as a kid learned basic, some of your audiences remember that language, uh, but was not a professional coder. Instead, I went off to the side of, of, of management and strategy and operations.

Matt: Management consultant, I worked in government reform. I got to enterprise software and [00:02:00] just fell in love with understanding and improving software teams and software organizations, and I started CIMA. Uh, Seven years ago, because I was so passionate about the need to, to bridge the gap between tech and non tech.

Matt: What do I mean by that? Uh, everyone on your, uh, everyone listening to your show is I'm sure very familiar with Salesforce and other CRMs. Those are great tools for individual coders, but they're also executive tools. The chief revenue officer can use it to explain the state of sales and the state of the sales team.

Matt: To the rest of the C suite to the boards of directors. So there's an executive level insight into, uh, sales, uh, thanks to code, of course, and there was not, and arguably still isn't in certain respects, executive insight into code, thanks [00:03:00] to code. And that was such an interesting, logical problem. Uh, such an important problem because when tech and non tech teams don't understand each other.

Matt: You know, less great things happen. And so we started SEMA, uh, to, to help tackle this problem. And it's been seven wonderful years. And today we do two things. We help understand and explain tech. in what we call moments of evaluation, like technical due diligence, um, you know, the buying and selling of software assets.

Matt: And we help companies manage how their coders are using GenAI to get the maximum, uh, ROI from using those GenAI tools while also minimizing the risks.

Mehmet: That's fantastic. Like, uh, we have a lot to cover, Matt, because one of the reasons this exists, to be very frank with you. Is because I like this intersection of business and [00:04:00] technology and, you know, you know, you just gave a brilliant example of salesforce, which is a software that usually salespeople use.

Mehmet: Like I use it also. I used to use it as well. And. You know, this, this intersection of both worlds, it's, it's like really, really important. And you mentioned technical due diligence and technical due diligence. So, so usually people in, in, in, I would say none, uh, as you mentioned, trust action based software selling.

Mehmet: I mean, like investment merger and acquisition. So when they think about technical due diligence, they might think, okay, it's just, you know, checking the quality of, of a software, but what I want you Matt to explain to us and to the audience, of course, um, when we say technical due diligence, when it comes to.

Mehmet: You know, a company that is [00:05:00] planning to acquire another company that developed a software or, for example, an investor who's deciding to put money in a startup that developed something. So why it's important to have this technical due diligence and, you know, from your experience, what would be like some common red flags, you know, in the code?

Mehmet: To whether the buyer or the investor.

Matt: Wonderful. You asked two great questions. I'm going to add a third. So first, why do technical due diligence? The extra one is what is technical due diligence, um, just to see your audience can hear the full taxonomy. And then the third is, uh, some, some red flags. Uh, so first, why do technical due diligence?

Matt: Um, there are two phases when it matters. One is, During, uh, before the decision is made, so actually deciding whether to make a go or no go decision [00:06:00] in, in, uh, the investment or acquisition, as you said. And the other benefit from doing technical due diligence is post close, what you could call value creation or just, just the next phase.

Matt: The reason to do technical due diligence it before making the decision is some companies, Pretty rare, but some companies have so many challenges with, um, the state of the codebase, and we'll talk about what some of those red flags are, that it makes sense to not do the deal. Um, examples, um, could be you end up having to spend so much money and time and effort trying to take the codebase to the state it needs to be that you would have been better off not, uh, not making the investment in the first place.

Matt: We like to say that in that phase, it's a one or zero decision. So extremely uncommon to say, well, the tech isn't perfect. It's not that tech should be perfect, but the tech isn't good enough to to [00:07:00] go through a deal, but it's, it's almost there. So we want to take 10 million dollars off the purchase price.

Matt: That's not how it happens. You either pass tech due diligence or you don't, which is why being ready for sellers, uh, and, you know, folks seeking investment to be ready for that, you need to pass. It's not, there's no, there's no gradiation. So it's, it's a really high stakes decision, even though most companies, uh, pass.

Matt: The other reason is that Because most of these deals pass the vast majority by the time you're doing tech due diligence, it's likely going to come, it's likely confirmatory is that, uh, it's an incredible opportunity to plan for the future. Uh, and so, uh, our clients, not just our clients, everybody, if you find findings, let's say you find security warnings, uh, in the technical due diligence, which by the way, all companies have security warnings.

Matt: That's not a reason on itself to kill a deal. Well, you have The work plan, uh, on what the company should do, um, post close, post investment. And so it's, it's getting [00:08:00] ready for the next step. So those are the two reasons why, or when I should say, uh, technical due diligence matters. What is technical due diligence?

Matt: So just very briefly in our world, this is about, um, the portion of an organization that has software developers, Either because it's a software company, or it's a company with software assets. If you think about that, that's almost every company on earth, because if software is eating the world, then almost every company has been eaten at least a little bit by software.

Matt: So it could be financial services, it could be pharmaceutical distribution, but what we're talking about is if the company has Coders, either in house or third party development shops, technical due diligence doesn't apply to COTS, you know, if you're just using commercial off the shelf software. In that world, technical due diligence is about functional assessment and non functional assessment.

Matt: Functional assessment is what does the product do, how well does it do it, [00:09:00] and what is the match or lack of match between current product and future product, meaning the roadmap, and customer requirements and preferences. The other part is non functional requirements, and that is how the codebase does what it does.

Matt: Within that, there are many sections. It includes code quality, like the architecture, like how much, um, how much testing there is. Those are some examples. It includes legal risk. That's actually one of the most important ones. Lawyers in transactions really care. And so, um, sellers or targets have to be able to explain their use of open source code, which while of course is prevalent, it's, uh, it comes with legal risk if you use it the wrong way.

Matt: And so we'll open source legal risk, uh, review is a huge part of technical due diligence. But real non functional requirements and really thinking about the code base goes beyond the code [00:10:00] itself, which is why we don't say code base, we say code. And this leads to the third, uh, the third example of, uh, the third question, which is, what are some of the red flags associated with, um, uh, with technical due diligence?

Matt: What, what are the reasons why, um, uh, organizations don't pass? There's really two, uh, two situations. One is, if you think of a scorecard or a set of traffic lights, everything is red or orange, um, which is to say there's high risk and high cost, uh, to, to improve the code across every, all of these facets of these non functional requirements.

Matt: But the other one, and one that I'm really partial to, because I, I like to think that we've, we've had a small, a small role in helping Helping non technical teams and deal teams understand this, the single most important factor in whether or not a code base passes technical due diligence. Mehmet, do you want to guess?[00:11:00]

Matt: It's not intuitive. It's not intuitive, but once you hear it, you'll say, Oh, absolutely.

Mehmet: What's it?

Matt: It is the presence or the absence for the risk of enough coders still working at the business who understand the code. Yeah, so we, we say code base because the code, the code base is so much more than the code is written.

Matt: It is actually the process, the developers, etc. Um, and so I know many of your audience members know this, but we like to say that having the code, the lines of code itself without having key contributors who understand the code is like having a A half written novel without the novelist. So code is never done.

Matt: It is a journey. You're going to have to, uh, clean it up. You're going to have to add features and functionality. It is a work in progress and losing [00:12:00] engineers who have the subject matter expertise to do it. In the code, uh, losing too many of them means it's, it's almost impossible to recover from. And so the single most important factor, uh, the single biggest red flag, if you had to pick one, is having all of the major developers of a code base, uh, leave, uh, leave in advance of the deal.

Mehmet: Um, you know, I'm trying to make a similarity. Like, uh, it's like you have a GPS navigator, but the satellite is turned off, right? So something like this, so, so you have the device, but you don't have the, whatever that makes the device works.

Matt: Exactly. It may be, if I could, it's like having the GPS device, but no driver.

Mehmet: For example, here you go. And I think, you know, this has. Underrated, I would [00:13:00] call it, Matt, because

Mehmet: I remember that maybe more than 10 years ago, maybe even 15 years ago. So I used to get involved in these conversations where usually people trying to, um, outsource the coding of, especially, you know, because the mobile app was the new thing at that time, you know, and you know, they used to write in there, um, when they are requesting for people to submit is I want to have access to the code or something like this.

Mehmet: And it's really funny because I used to tell them, okay, if you have the code and, but you don't know what to do with it, what What's the use? Right? And from my experience, what I have seen also, like, I'm not a coder also myself, like, I know how to code, but I don't claim I'm a coder. I never, you know, did it professionally.

Mehmet: But the thing also, I say, like, it's what I hear from coders, [00:14:00] it's very hard, even if you have proper documentation to code. To understand it, it's going to take time. I'm not saying it's impossible, but going to take time. So Matt, like this is very interesting, but this is to me, something which should be proactive, not a active act.

Mehmet: I mean, the due diligence. So when. You talk to CTOs. I think you're, you're, you know, I would say the people who must worry about it are the CTOs the most, right? And even maybe the CEOs. So do they see this as a necessity only for the sake of an evaluation or a valuation or maybe, or do they understand that there is, this is a real risk.

Mehmet: For their business, like, do you, do you see like, this is something that is evolving?

Matt: Yeah, great question. Thankfully for, um, for the state of the CTOs and for their [00:15:00] organizations, almost every CTO understands that we've spoken with and, you know, we've, Seema's worked with more than a thousand organizations.

Matt: We've looked at more than a trillion dollars worth of code all the way from, you One person organizations to public companies. So we've, you know, we've seen the range, almost every CTO understands the importance of, um, understanding and improving, um, or at least managing, let's say understanding and managing the state of the code base, not just for the purposes of diligence, but because it's the right thing to do.

Matt: ongoing. And, you know, if you take, you know, anything, anything more than the smallest of companies, where all they're working on is product market fit, and they should, and just working on the functional requirements, can they build [00:16:00] something that somebody cares about, which is, of course, it's incredibly hard problem, and they should be focusing on that.

Matt: Beyond that stage, every organization on, you know, software organization on earth has some degree of concern about non functional requirements. You see that in the prevalence of, um, of code quality tools in the SDLC, sometimes, uh, open source, uh, legal or security risk tools in the SDLC, code quality tools, et cetera.

Matt: Of course you see it through code reviews, et cetera. If I could wave a magic wand, you didn't ask, but I'll answer. I would, there's two things I'd like to get a little bit better. I'd like to see a little bit better in the state, uh, state of the world. One is, um, for the rest of the organization, um, to.

Matt: Understand and to listen to the CTO about, hey, we need to make an ongoing investment to make sure our code base is within range. Now, code bases should not be great. They should be great on functionality. They don't need to be, quote, [00:17:00] great on, uh, Um, non functional requirements. They need to be good enough for the stage industry of the business.

Matt: That's a super important point. You should not companies should, uh, software teams should carry technical debt, security debt, quality debt, et cetera. It's not zero debt. It's not perfect code. That's not a good, that's not a good business answer, but they should be managing it. And so we would love, uh, CTOs.

Matt: Uh, sales teams were always pushing for more on the road map and finance and boards to understand, hey, we have to invest. And it's not just up to the CTO because CTO gets a budget of how much they can work on it. They don't have a budget for fixing quality or security, et cetera, but there's nothing they can do.

Matt: So I would really like them to, uh, the other parts of the organization to understand. The second way to wave a magic wand is that CTOs have a role to play to this, which is Making non functional requirements [00:18:00] understandable to the rest of, um, uh, to their counterparts, even when they're less technical. Um, you know, I don't know if it's an American expression, but it takes two to tango.

Matt: So, uh, which is to say, in this case, if you want an organization's leaders to understand the state of the technology and what to do about it, Non technologists need to be curious, but technologists need to be clear. If I came to you and said, Mehmet, we need to do service oriented architecture, and it's going to take 20 million, and just trust me.

Matt: Maybe you get it. I don't mean you, but let's say someone less technical. Maybe they get it, maybe not. If you say, we are in the bottom quartile on code quality and performance. measured by architectural risk relative to companies of our size and stage. And that bottom quartile puts us at risk. Um, that all of a sudden puts this in context, right?

Matt: Because now [00:19:00] non technologists can understand what's going on. So those, that's my wish list. Uh, you didn't ask, but I'm going to answer because we're so passionate. Other rest of the organization listened And CTOs Um, find ways to communicate in a way that makes it easy for them to understand.

Mehmet: Absolutely, because business people, they need to see the things in terms of numbers usually, right?

Mehmet: So, so you can relate to that. Of course, um, to be very frank with you, Matt, like, of course, things are changing very fast. And of course, like business people, they are, At least from my experience, more curious to understand from also technical perspective that, but what will make them take the decision is the number, right?

Mehmet: So you're not, you need to show them a number, whether it's like increasing revenue, decreasing a risk, whatever it is, right? So, so increasing valuation also maybe. So, so this is how, how business people, they act now want to come to something, which when I was [00:20:00] preparing for, for the episode, it's very interesting.

Mehmet: And it is the use of AI generated code in software development today, which is something which also you focus on as well, Matt, right? So, and this is becoming very, very fast. People are adopting different tools. So just for the sake of transparency, we are recording on the 6th of September. Probably this will be at the end of September or, you Maybe beginning of October published, but a couple of weeks ago, I started to see a lot of things around tools like cursor AI.

Mehmet: And there were like a lot of buzz about co pilot from Microsoft and many other tools, right? So what are the risks, Matt? And especially you talk about investors that, sorry, risk that investors should be [00:21:00] aware of about when assessing the code base. What, what are these risks?

Matt: Mehmet, you told me to be authentic, so I'm going to be authentic.

Matt: I will answer, but I'm going to start with another one first, which is what are the benefits? I will start with the benefits. Okay, sure. We are emphatically supportive of using generative AI tools for coding, and there are two categories of reasons, but they're huge reasons. One is, used correctly, Generative AI tools can produce a meaningful, meaningful, meaningful, um, uh, productivity input, uh, productivity benefit, I should say, for the engineering organization as a whole, uh, at least 10% Um, uh, at least 10 percent based on our based on our studies.

Matt: Now there's a lot of hype about some extreme numbers Even if the number is just 10 percent Uh, that is an extraordinary impact on product roadmaps [00:22:00] on organizational effectiveness uh, and it's One of the largest if not the largest change and benefit to software development in the last 25 years, you know, it's certainly as big as, as the, the, the rise of open source code.

Matt: The other benefit, if one is, um, uh, impact benefit for the organization, the second is benefit for coders. And, um, as you're about to see in a second, we are emphatically, uh, believers in humans staying in the loop. Uh, so this is not about, uh, replacement of coders. This is about helping them do more. Um, Gen AI code can help prototype, can help explain code, especially as you said earlier when you're trying to figure out what, what code does.

Matt: It can help error check. It's like a, um, it's like a, um, a buddy for, for peer reviews when you need one, there are so many benefits to the quality of life, quality of work life for developers. If there were risks, you know, anything comes with risks. [00:23:00] If there weren't substantial benefits, who cares? But there are substantial benefits, which is why the risks are, uh, are really important.

Matt: And so we think about those briefly. We see five main risks, and I'll just share them briefly and happy to talk about any of them in detail. One of them is insufficient use of Gen AI coding tools, leading to an organization not being as effective and not being able to take advantage of the productivity gains as possible.

Matt: So if, if everyone else is using Gen AI, which is the case, or Gen AI coding tools, and you're not, you could be at least 10 percent less productive. Uh, effective than your, um, uh, than your competitors. Second is intellectual property risk. If you use coding tools the wrong way, you put the IP at risk, especially by the way, uh, if you don't manage the tools, which tools developers are allowed to use.

Matt: And also, especially if you're an organization that cares about copyright protection for your software. [00:24:00] Third is security risk. All code comes with security risk, whether it's written by humans on the team or open source or a gen AI tool. Uh, but it comes with security risk that needs to be managed.

Matt: Fourth is maintainability risk, which is to say code a gen AI code may not be understandable. Uh, and if it's not understandable, it may not be maintained. Again, if used incorrectly, there are definitely ways to manage all these risks. And then fifth is sort of an add on category, but if you said for investors, it's really important, which is just exit risk.

Matt: On top of all of those other reasons, companies, um, to a much greater extent, um, uh, to a growing extent, we'll have to justify. their gen a I use, um, in diligence. Um, and this, you know, it's I love technology sometimes changes quickly and sometimes not. This is a story tech to diligence usually doesn't change quickly.

Matt: But this is a story that basically happened overnight. Less than a year [00:25:00] ago, some major major software acquirers and software investors, um, decided that they needed to start managing the risk of generative AI in their potential acquisitions or targets. They commissioned an organization, which was SEMA, to build a tool to manage, to measure how much GEN AI was in codebases.

Matt: And it's now in production and use by the entire world. A disproportionate share of the world's leading software investors, late stage software investors, private equity and strategic acquirers. And so now, uh, companies and to an increasing degree, we're going to have to justify are they using the right amount of DNA?

Matt: not too little, not too much. And are they using in the right ways that solve the other four risks?

Mehmet: That's, uh, you know, really interesting, Matt, because if you tell someone about the concept of, uh, [00:26:00] auditing the use of Gen AI in coding, probably two years ago, Some would say, what? Like, you know, that, that doesn't make sense to me.

Mehmet: But, uh, of course, you know, the past two years, like, we're like really a ride, I would say. So you call this, I think, Gbom, which is generative AI build of materials, right?

Matt: Yes. So the topic of understanding how much generative AI is in the code, we call that GenAI Code transparency. Now, one of the things we learned as we built this is there's a lot of parallels to open source code.

Matt: What is open source code? Of course it is code not written by the team. It's written by, in this case, another organization, a community. It's a really good idea to use open source. If you ask the developer, do you think that open source is a good idea? They'd say, absolutely. Why should I reinvent the wheel?

Matt: It's going to get to higher quality, et cetera, et cetera. So good for coders, good for the [00:27:00] code base, good for the organization. But open source comes with risk. It has security risk. It has intellectual property risk. It has operational risk if it's not maintained. Well, guess what? All of that's true for Gen AI.

Matt: Gen AI code is code that the team did not write. The team prompted it. But the LLM wrote it. So they didn't write it. It comes with huge benefits to the coder and to the organization. And it comes with risk. Uh, that risk of, um, security, IP, all those things we said. So a lot of this, um, a lot of the work on Gen AI risk and benefit management comes straight from open source, uh, um, risk and benefit management.

Matt: I say that because there's already a term of art. Software Bill of Materials, which refers to, or SBOM, how much open source is in the codebase, and what are the risks associated with it. Uh, we're honored that we invented the Generative AI Bill of Materials, or GBOM, to keep track of how much Gen [00:28:00] AI is in the codebase.

Matt: So a slightly longer answer. The topic is Gen AI code transparency. The document, the document form of the output is a AI bill of materials.

Mehmet: Absolutely. I can relate to something that happened, I think, two or three years ago. I can't remember. Um, regarding the use of open source, there was this famous library called log4j.

Mehmet: Exactly. Look for J was used. I don't know, countless amount off of software because it's a an open library that majority of vendors there are software vendors they rely on. And there was a, uh, I think there was a, uh, a vulnerability in, in one of the versions. And then, you know, like every, it was like a mess for almost six, seven months.

Mehmet: And I think the same thing apply here, Matt, when using the generative AI, it's not because the generative AI is bad. [00:29:00] You know, I just want to highlight this too. And you just did also as well. So this is because this is how software works. Like sometimes it can have bugs. Sometimes, you know, it needs to be updated later on out of curiosity, Matt.

Mehmet: What I, of course, I didn't go deep dive after this, but probably you're seeing this more than me. So people, they just read the code one time and I feel, I have the, the, the feeling that, Oh, they say, you know what? Our job is done. Like it generated the code. I don't need to go. It works. Performance is okay.

Mehmet: So are you seeing people like trying to Ask these LLMs. Okay. You gave us, for example, version one. Now give me version two, like evaluate your, your own code and give me version two. Or like, let's say, let's enhance and come up with version three. Are we seeing something like this happening?

Matt: It's a really, really good question.

Matt: To take a step back, there definitely is evidence. I believe it was a Cornell University study [00:30:00] that Gen AI code comes with security warnings as does all code. Exactly as you said, as does all code. But worrisomely, um, The developers were more likely to trust it, uh, even though it has security warnings in it.

Matt: So the we're done phenomenon certainly exists. The good news is certainly from SEMA's, you know, qualitative and quantitative experience is that certainly the vast majority of professional coders, um, understand that they cannot rely on the code itself. Um, One, they come back and ask for better versions, but I'd say even more importantly, they run it through all of the, the quality and the security checks, um, that they would any other piece of code, which is exactly how we would think of doing it.

Matt: It includes high quality security tooling. It includes high quality code quality tool tooling. It includes code reviews, one of the most important elements of the software development [00:31:00] lifecycle, both to improve the code and to spread knowledge and to increase training. Professionally, uh, professionally, uh, organizations have gotten the message that you cannot trust gen AI code, uh, alone.

Matt: You need to put it through, you know, all of the quality gates and, you know, quality broadly defined. A side effect of that, um, if you think about, just use our terminology, there's Gen AI originated code. Once it's originated, it could be pure Gen AI code, which is to say that a developer hasn't modified it, or it could be blended, which is to say a developer took it and, um, and then modified it to improve these issues, uh, potential issues.

Matt: Um, organizations, elite organizations. Not only manage how much Gen AI originated code there is, but also how much or really how little pure Gen AI code there is. Because if you, just an extreme example, Mehmet, if you got a code base and [00:32:00] it was 100 percent coming out of prompts, you should be really nervous.

Matt: Um, if it had any high stakes purposes, really nervous that, you know, literally by definition, no coder improved it. impossible that that would be the best code. And so GNI code transparency includes not only how much GNI originated is there, but how much has it been blended as a leading indicator that the development team has the resources and capacity to, to make that code better and safer.

Mehmet: Got it. Now, a little bit of a futuristic question, I would say, because I had this discussion with other guests on the show. Do you see in the future, like, Gen AI being more capable of being, you know, doing more than what it just does today in the sense of software engineers becomes more kind of project managers or product managers, and we have the AI, you know, [00:33:00] acting as.

Mehmet: A bunch of agents that someone works on this library, the other works on, I don't know, like maybe a user interface, the other working on an API and, you know, someone comes and just check what they are doing. Is this something too much futuristic, do you think, Matt?

Matt: So absolutely, positively, Gen AI coding tools will continue to improve their efficacy.

Matt: No question. Um, by the time that this, uh, by the time that this podcast is released, if they will be better, I mean, the, the rate of change, and you mentioned this earlier, more than a billion dollars have poured into, um, uh, specific gen AI coding tools, much less the. I say generic, but they're incredibly powerful and incredibly strong, uh, tools like ChatGPT and, um, not even counting, you know, GitHub Copilot, et cetera.

Matt: So a huge amount of money and resources are being put into this. I take a long [00:34:00] view. I studied history, uh, I, uh, I studied history in college and I like to bring a historical view. As I mentioned, um, son of a coder and a math teacher and my, uh, in fact, my math teacher mom was a coder before that. In the sixties, this is a history lesson.

Matt: Coders used punch cards. Google it if you don't believe it. It kind of looks like a library card if you even know what that is. I'm, so old I had library cards also uh that fed ones and zeros, uh into machines that were the size of um, size of large rooms,

Mehmet: right?

Matt: I 2010, um, so many changes happened, but let's just talk about open source.

Matt: And I like this idea of project management. Um, a coder would not just, uh, take requirements from the product team and write every single line by hand. They would say, huh, We're building a web interface. I'm not going to build a framework by hand. I'm going to go to open [00:35:00] source, and I'm going to find the right one.

Matt: I would argue that that is the gen, that is a coder serving as a project manager by not doing everything themselves, but by going and finding the right answer. And it doesn't mean that there's no work involved, and it doesn't mean there's not a human in the loop, but it would be bananas. And I picked 2010, a period where open source is in use, but not Gen AI code, where they are already project managers.

Matt: Now fast forward to today. There's another kind of project management capability, which is now you have um Uh, now you have Gen AI as an option, AI code as an option, just like Stack Overflow, just like Open Source. And so, the project management ness of, um, the project management nature of coders from the 60s, from the building of the Apollo, um, you know, mission controls and other systems, has dramatically increased as a percentage of their time.

Matt: And that rate will continue. I'm just looking at the historical rates. But fundamentally there still is an incredibly important role [00:36:00] for developers in that process. And as much as code is eating the world, there's so much more digitalization to happen. Um, as crazy as that sounds, it's absolutely true. And so, uh, there will be plenty of work for coders who are both coding, And project managing, um, just in slightly different percentages, um, to continue to digitalize and improve the world.

Mehmet: Very interesting point of view, I would say, Matt, um, which kind of I agree with, to be very frank with you. Now, let's talk, if we can, about value creation for software companies. Um, so there's, I believe, like a technical standpoint and aspect when it comes to, you know, improving the yield of a software company during the acquisition process.

Mehmet: So, uh, I'm interested to, to hear from you, [00:37:00] uh, Matt, about like how they can do this. while balancing between innovation and operations.

Matt: Got it. And so we're using the same terms. When you say value creation, you mean, uh, her, I would mean it, um, after an organization has been sold or acquired. So a new investor or owner, the period after, Technical due diligence is done after the deal is closed.

Matt: How to make the company better a company with software assets. Am I thinking about that? Right?

Mehmet: Yes. A hundred percent.

Matt: Absolutely. Um, you know, I like frameworks, so we'll start a little bit on the framework side. Um, of course, of course, of course, sales is King. Uh, and so we want to think about value creation from technology to boost revenue, um, and then we want to think about cost and then we want to think Risk incredibly [00:38:00] straightforward framework.

Matt: I know, um, there is almost no organization. I would say no organization that couldn't benefit from technology, uh, serving as an improvement to, um, uh, to more revenue and more of the right kinds of revenue. There's just no substitute for building, developing, acquiring the best possible product management function You can shout out to Alex and Ankar.

Matt: I love you guys so much. Uh to um Really really listen to customers and prospects on the job to be done. Uh, what do they actually need help with? and You know, what are they saying and what are they not saying about the problems that need to be met? So first and foremost, we we try to drive revenue because that makes that always drives.

Matt: Um that valuation Um, can we get better and better and better? It's a continuous process. You're never done with listening to customer [00:39:00] requirements, deciding what they should actually be, and then translating that into, you know, feeding the engineering team. In terms of risk mitigation, um, you know, I, I'm biased, of course, we've done so many tech due diligences, but I, I think, I think investors are smart.

Matt: And I think the standards that they care about in diligence really serve as a good, um, You know, a chart, if you will, a checklist, a credit score of code, like you got to care about development process consistency. You got to care about carrying the right amount of technical debt about, um, code quality, intellectual risk, property risk, et cetera.

Matt: Not too advertorial, but you can go, we have some blogs on what metrics to care about. We even have a self serve calculator if you want to see how you stand up. So we, you know, we want to educate the world. This, we think, are the right sets of metrics to think about to mitigate the risk, um, to mitigate the risks.

Matt: And then on cost, This is, I think, true for [00:40:00] every department, which is you should always be looking at what are we spending? Uh, are there ways to achieve the same outcomes? Um, um, uh, well, and that's both purchase spend, um, uh, and, uh, uh, purchase spend. And of course the team, um, friendly reminder, if you are not world class at managing your cloud costs, please go find a consultant.

Matt: That's not SEMA. We don't do that for a living. Please go find somebody to do it because it's frequently the, um, low hanging fruit if you really bring in an excellent person, whether full time or a consultant, um, to, uh, improve your bottom line, improve COGS, improve net income without, uh, without team disruption.

Matt: So we really like, uh, looking at that, um, you know, early in the whole period.

Mehmet: Absolutely. Like again, great insights, Matt. Um, as we are like almost coming to an end, just, you know, one thing that, uh, I'm [00:41:00] curious to know from, from your perspective, especially like with what you're doing currently with SEMA, um, other than Gen AI, like, what do you think Um, some other emerging technologies, of course, like JDI is the biggest one.

Mehmet: I'm aware of that, but what would be like some other aspects that you, you expect, uh, to have great impact on technical due diligence in, in the future.

Matt: On technical due diligence. Okay. I thought you were going to say on value creation on engineering. I came back to tech due diligence. Yeah. Got it. Um, I'm going to cheat a little.

Matt: You can, you can call me on it. Absolutely, technical due diligence on the use of generative AI in an organization is a huge trend of which there are two parts. One is, um, generative AI. To [00:42:00] write the code. Another is gen AI in other parts of the business. Um, whether it's part of the product, like a chatbot powered by AI, or whether it's, um, not customer facing, but part of, Products or operations, underwriting, drug discovery, um, you know, are all being revolutionized by Gen AI.

Matt: And so understanding that as part of, um, the technical due diligence process, understanding the use of generative AI is of course, a major trend. The other one that I'm cheating, um, your audience, if you can see me, I'm smiling. The other one is. Using Gen AI in technical due diligence. So, document review is fundamentally different, um, because of tech, of, uh, Gen AI's ability to summarize and synthesize information.

Matt: It's not 100 percent accurate. It hallucinates, it's not a substitute for human judgment. It is just a bionic [00:43:00] advancement of it, which also, by the way, is exactly how you should think about gen AI in all cases, helps humans do better, but you got to, you need them. Uh, and so we are seeing in the technical, the technical due diligence process, absolutely being transformed by the ability to, uh, To use gen ai tools to understand organizations even better.

Matt: So i'm a little bit of a one trick pony What is changing is gen ai, uh in tech due diligence, but there are two major components such that tech due diligence Today is already quite different from two years ago and will be Uh quite different again, um two years in the future

Mehmet: fantastic Finally met Anything you want to leave us with today, maybe something I didn't touch base on and where people can get in touch with you and find more about SEMA?

Matt: What a great question. You're such a great interviewer, Mehmet. [00:44:00] Nothing, nothing new comes on, but I think what I would, comes to mind, but I would really emphasize a point you made, which is making code engineering understandable and understandable. To the rest of your organization. If you are not currently one way or the other able you, a CTO, I'm not currently able to contextualize and synthesize the state of engineering into what you're Dollars and cents, relative comparisons, traffic lights, things that, um, uh, things that a non technical expert can look at.

Matt: If you can't put it all in half of a page, the state of what's going on in engineering, half a page with terminology that's very simple, you have work to do. Um, uh, and so there are ways to do that. Of course, we would be happy to help. Um, but CTOs make, put in the effort to make it understandable. [00:45:00] Um, like, like Mehmet said, and, and that you'll pay off huge dividends for, uh, for your organization.

Matt: So that's why if I had to say one, the last thing I would leave it with that to find us, um, I would be delighted to talk with any of your listeners individually. If you go to simasoftware. com, you can see it, S E M A software. com, one word. Any of the contact us buttons will find us. You can also find me on LinkedIn at MVI.

Matt: LinkedIn slash in slash MVI Matt van Itallie. Any of the find us buttons will get to me. I would be delighted to talk to any of your listeners.

Mehmet: Thank you very much, Matt, for, you know, this insightful, uh, episode today and, you know, something which we didn't touch base on, uh, before. So this is like kind of, uh, a great use case for a lot of startup founders, for a lot of even like properly, uh, you know, software houses as they call them.

Mehmet: Right. So because they need to be aware of this [00:46:00] topic also as well. So great insights for the listeners, all the links that Matt just mentioned, you can find them in the show notes. Or if you're watching this on YouTube, you'll find them in the description. And again, Matt, really, I enjoyed this conversation with you today.

Mehmet: So. I hope we can do another episode also in the future because I think this is a very very hot topic And this is usually how I end my episode. This is for the audience if you just discovered this podcast by luck Thank you for passing by if you liked what you heard or what you saw today Please give us a thumb up and subscribe share it with your friends and colleagues And if you are one of the people who keep coming back, they keep sending me their feedback their suggestions Thank you for doing so keep them coming.

Mehmet: I read all your notes, remarks, and I try to take action on the things that I can do. So thank you for doing this. And as I say always, thank you for tuning in. We'll meet again very soon. Thank you. Bye [00:47:00] bye.