Matt Van Itallie on Sema Software's platform that powers technical due diligence for executives and provides tools to find and fix technical debt

Matt Van Itallie of Sema Software - Podcast Transcript

Scott:	Hey, it’s Scott Orn at Kruze Consulting and welcome to another episode of Founders and Friends. And before we start the podcast, let’s give a quick shout out to Rippling. Rippling is the new cool payroll tool that we see a lot of startups using. Rippling is great for your traditional HR and payroll. They integrate very nicely, but guess what? They did another thing, they integrate into your IT infrastructure. They make it really easy for when you hire someone to spin up all the web services and their computer, which sounds like not a huge deal, but actually we did the study at Kruze. We spent $420 on average, just getting a new employee’s computer up and running and their web servers up and running. It’s actually a really big deal. It saves a lot of money and the dogs are in the Dogwood. We see a lot of startups coming in to Kruze now using Rippling so, please check out Rippling, great service. We love it. I think we have a podcast of Parker Conrad. You can hear it from his own words, but we’re seeing them take market share so shout to Rippling and now to another awesome podcast at Kruze Consulting’s Founder and Friends. Thanks.
Singer:	[singing 00:01:18]. It’s Kruze Consulting, Founders and Friends with your host Scotty Orn.
Scott:	Welcome to Founders and Friends podcast with Scott Orn at Kruze Consulting. And today my very special guest is Matt Van Itallie of SEMA software. Welcome, Matt.
Matt:	Thank you for having me, Scott.
Scott:	My pleasure. We were just exchanging emails and I have an M and A background, and you were telling me what your software can do. And I was like, oh my gosh, you got to come on the podcast. So, can you retrace your career a little bit and tell everyone how you had the idea for SEMA software?
Matt:	Absolutely. And thanks again for having me. So, I was a coder very early on, literally with cassette tape memory, just to date myself a little bit coding and turtle basic, but then went off to the organizational side and helping improve organizations. And so, after a stint in consulting and then government service, I served in software companies and the story of SEMA came about two big ideas at once. Spending time with our software team. On the one hand, the CTO went into the CFO and ask for money for a service oriented re architecture. And I happened to see that conversation. And you could see really nobody else in the room besides the CTO knew what a service-oriented architecture was much less how much it should cost and whether it was the right idea.
Scott:	Yeah.
Matt:	She was right, of course the CTO, but it was really hard to explain to non-technical folks. And then the other part of the equation was watching my friends on the development team, really re architecture through old legacy systems and trying to untangle the spaghetti code, we like to say. My experience, our experience is maybe one developer out of 20 really likes dealing with old code, but everybody wants to create new.
Scott:	And probably the old code wasn’t documented as well as it could have been. And it’s so old that there’s no one around on the team that you can talk to, to actually help decode it.
Matt:	Exactly right. With all of that turnover, it’s incredibly hard to find a helper around to help. And so you combined, I saw those two factors at once and truly I looked at what was sitting across the table from the sales team and with a push of a button from our CRM, we got that information. In fact, nobody ever thought about it. It was so obvious. Of course, you knew the quality of sales and where you needed to dig deeper. You also knew the ways to coach individual salespeople. You would never run an organization without a CRM with that quantitative data that everybody understood. Of course, CRM is code. And I was really flabbergasted when I thought about the analogy, do you mean we have code that helps us understand and improve sales and salespeople, but we don’t have code to help us understand code and coders, at least at the level that we would want? It just totally didn’t make sense.
Scott:	Yeah. Someone should have eaten their own dog food a little bit and built that, right? That’s an amazingly, because there’s code for accountants to make accountants more effective and salespeople, and pretty much every function. That’s really funny.
Matt:	The deep tech folks listening. There’s an incredible piece called, how to write unmaintainable code. It’s totally tongues in cheek about all the ways it’s hard to be a software developer, but the kicker at the end, it’s called the shoemaker’s sons have no shoes. And he’s complaining that we’re writing very complex systems with very rudimentary tools. The kicker is the piece is 20 years old, but could read exactly like it was written yesterday. So, I highly recommend it. How to write unmaintainable code. So that was the origin story of SEMA and with the help of some fantastic engineers, we went out and built it. And so, what we have built is a business intelligence layer. And I actually do want to mention that point briefly. CRM of course, is an incredibly important tool, but with non-trivial setup taking all of the data from lots of different places and then putting it together, it’s both the analytics, but the underlying data. The beautiful thing, the amazing thing about doing this on code is that structured data already exists. So, when I say business intelligence layer, it literally sits on top of GitHub or Bitbucket or TFS or any of these version control systems. And so, the shorthand of this is what would you do if you had CRM like data about code and coders tomorrow? And I really mean that. We set up takes 15 minutes of hands on keyboard and then processing takes an hour to overnight for medium sized companies. It’s all of the power of the insight that you would get in CRM without a three to 12-month implementation.
Scott:	Yeah. We were talking before we turned the mics on that like what a gift GitHub is to you because when we were talking about, I hadn’t put it together that like that CRM example, like yeah, when we switched over to Salesforce and had to load all of our old conversations, contacts, all that stuff in, and like that wasn’t just sitting there, but for your use case it’s sitting there in GitHub, and the legacy is sitting there too. It’s pretty cool.
Matt:	Yes, and all of that, there are some, GitHub of course it’s very popular, but there are many other systems that folks are putting in and to do this right you have to work across them, but absolutely. It is structured data ready to be analyzed and ready to be analyzed quite easily. And so, what our system does with that long intro, is take this business intelligence layer and we actually look at the quality of the code, the quality of the development process, the contributions of developers, the intellectual property risk associated with the code and the security of the code itself. And we put all of those pieces together through our reporting engine and can deliver reports, and of course we’re talking today because one of our most common use cases is using this in M and A.
Scott:	Yeah, before we get to the M and A stuff, I also hadn’t, until we started talking now, hadn’t put together that you could actually isolate the code of individual developers, which is like the story of like the 10 X developer that I read about on Twitter all the time. And we work with some really great people at Kruze. And I never thought about that, but your software could actually determine who is a 10 X developer or, I’ll take a five X developer any day of the week, right? Kind of thing. But like, that’s actually a really cool thought to in the same way that like Salesforce tells me who the best salespeople are in our organization, you can actually determine who the best developers are. That’s really powerful.
Matt:	It’s true. And it even goes a step further. First off, you’re exactly right. Not only is the data of code structured, but it’s timestamped and stamped by developer so, that’s exactly how you do it Scott. If you and I were coding together in the same part of the code, and I wrote at time zero, and as a result of me and everyone that came before me, there were a hundred bugs in the system. And then you made changes to the code you committed. And now all of a sudden there’s 90, you took out 10 bugs. So, we can attribute to you that you are a bug remover and that attributes to skill. And so again, one of the incredible things about the space, the measuring of the productivity of developers has been around for a very long time. There’re better and worse ways to do it. A lot of worse ways, someone wrote 10 lines of code…
Scott:	I mean it used to be like lines of code, right? And then people realized that was wrong.
Matt:	Yeah. There’s an amazing [inaudible] about a bug bash competition. And the person who wrote the most lines of code, coded himself a minivan. I mean, it’s just not the right way to do it. The right way to do it is not only a comprehensive picture that takes into the context. The context is absolutely key, but also a step than what CRMs can do. The measurement of developer’s contributions contains the specific coaching to get them better. So, it’s not just, ‘Hey, you stole [crosstalk] ‘ it’s, using our previous example, ‘Hey Matt, you introduced more bugs of this type. Here’s the line where you did it. Here’s the kind. And so, you can get better.’ And so, the North, we absolutely have found a way to measure developers, skill and contribution. The North star is making the code better and helping developers be better at their craft. And so, it becomes a self improvement and coaching tool as much as it is in situations like M and A or another popular use case is working with third party development shops.
Scott:	Yeah. When you’re working with an organization or you’re coming in to do this, are you like, I could see that being a really strong pitch to the top developers in the organization, because they’re all of a sudden, maybe they’re fighting for recognition or maybe aren’t getting enough recognition or whatever. And all of a sudden, there’s this new tool that’s going to tell everyone how great they are. I mean, is their customers putting that together or is that a little too, drinking the Kool-aid too much?
Matt:	You’re very kind. And I’ll tell a little bit more about my background and I said, I was in government service. I had the pleasure of working with urban school systems on data systems, putting in systems to help understand teachers and principals’ impact on the levels of student learning. If you start the school year at the second, if everyone’s reading at the second-grade level and the end of the year at the fifth-grade level, there’s a magic in that classroom that you really want to duplicate. So, have many years of battle scars of bringing in quantitative data to the field of education, as it turns out, and I’ve absolutely, I’ve come to believe this for very good reasons. Professionals who aren’t used to having quantitative data are very skeptical regardless of their quality level and for good reason, that there’s so many ways to use data about people the wrong way. It’s the context to understand the operating environment. It’s true in education, but it’s super true in code as well. There’re a million examples if there’s not a lot of unit testing. Testing is a good way to make sure that the code is high quality and very rarely has something to do with the development team. It has everything to do with the budget, allocated to the [inaudible] team. And so, in fact, SEMA highly recommends staying away from using this on the developer side for ongoing usage for a very long time, just start first with helping get the code better, [inaudible] tooling to save time and build new features instead of working on the past, the good news is as they do that, the quality level of the code improves and developers can become better developers. We really do, it’s a little bit paradoxical, but we really do stay away from it for ongoing use. We don’t think, it’s usually not fair to developers.
Scott:	That makes sense, and it’s also, I mean we have a lot of quantitative scoring systems internally at Kruze and you’re right. When we first introduced that stuff, it was, people got a little scared and nervous and so I can totally see how that would work, but I think they probably are just by using it, maybe they, if they recognize that or not, they are getting better because they’re seeing like, Oh my gosh, if I just use this one, different segment here, then I can get this done faster and it’s more accurate so, that’s really neat. I mean, that’s, I feel like you’re doing like Moneyball for a baseball player or something like that.
Matt:	We definitely…
Scott:	Recognizing the guys who take walks.
Matt:	We definitely use the sport’s analogy. You’re right to say it. And you think about playing basketball without a scoreboard. And then all of a sudden, a scoreboard is introduced. Sure, you could use that at the individual level and keep track of individual stats, and of course people do that right? It’s well established, but the first use case is kept track of how well your team is doing and the way that your team can get better and that’s the evolution of metrics like this. Start by the team contributions, the impact and then you can work your way down because as you said, if your team is winning, you’re obviously contributing to that, and that’s the place to start.
Scott:	Yeah. I love it. And then, so let’s talk about the M and A use case, because I used to do M and A and one of the observations we’ve had as a company at Kruze is that like a lot of venture capital funds, I used to work in venture capital too. So, I know the whole industry, a lot of venture capital funds have, they’ve raised bigger funds and now they’re almost like a financial manager and less like due diligence providers. So, like, what you used to see in the old days was like the partner and the associate would conduce the venture capital due diligence, all the numbers and all the products and everything. And now that industry has gone to like the partners are just, they’re trying to do deals. They don’t really have time to do like the hardcore diligence. So, what we see on our side is they’re hiring like big four accounting firms. And so, we, it’s not an adversary relationship, but what we’re going up against big four accounting firms all the time now in either M&A, or in big rounds, and it’s not adversarial, they’re just like, they’re doing what they should do. They’re checking underneath the covers to make sure everything’s done correctly and things like that. And so, we actually like it because it’s a nice validation for us. And so, I was just like sitting there one day and someone had talked to me about helping out in technology diligence. And then you and I are exchanging emails. And I was like the light awaken in me because it seems like SEMA is like God’s gift to technical due diligence for venture capital firms. And even in M&A, am I overstating that or? It seems like you guys have a really great value prop in that situation.
Matt:	Well, you’re very kind and it is in fact, true. We do a lot of work in M&A, fortunate to serve Fortune 100 M&A teams. Some of the world’s leading investors in companies that have software assets, whether or not they’re software companies. And we do so both directly and in partnership with great consultancies, global consultancies and boutiques. Now that I’ve persuaded you of the CRM analogy for what we’re doing, let’s play this out in the M&A case.
Scott:	Yeah.
Matt:	In 2020 for a company that had more than a million dollars of revenue, rather, even less than that, you would never in a billion years buy it or invest in it unless you could both, interview the head of sales, interview some customers, look at a couple of contracts, talk to a sales person or two, and you know where this is going, look at the CRM. So, an organization again, tiny, no, but after a certain size, pretty quickly having a CRM itself is an indicator that you’ve reached a certain level and the data is, it’s literally a deal breaker. You would just simply wouldn’t do it. SEMA sees ourselves very much as providing that quantitative data to supplement, it must be done together to supplement the great qualitative assessment of internal teams. If it’s a tuck in, a CTO, if it’s a consultancy for external teams, but the two together are so much more powerful than either one alone.
Scott:	I love it. So how does the flow usually work? Like you’re working with a big consulting firm or you’re working with the CTO and they maybe let the audience [inaudible 00:00:16:19], like they pick up the phone, they call you, you come in and how fast and how quick the results do it happen?
Matt:	Sure. High level first, it takes a week for small to medium companies from first conversation with the target to finished report, medium companies to large, up to two weeks and sometimes even large companies, we can go that fast. So, part of our amazing engineering team’s work is to make this work incredibly fast, to meet the diligence timelines. A way that SEMA is able to do this is that we serve as a trustworthy third party. In fact, we do a lot of work on the buy side. We also do work on the sell side. The data is the data we’d like to say that we’re Switzerland. If a company is getting ready for sale and they enlist us, which happens, we would say the same thing about them as they would if we were representing a buyer, of course, a seller doing this has an advantage of several months to get ready and adjust and…
Scott:	That’s actually very smart. I hadn’t thought of sellers doing that. But you’re right. Like when we have companies going in for a VC round or M&A, we know, I mean the good companies they’re organized. They have a methodical path. They’ve scripted everything out. So, they know like two months ahead of time or three months at a time. So, you’re right. A seller or a startup that’s going to go through technical due diligence can actually use your software to prep for that.
Matt:	And not only have an explanation for shortcomings and of course no code is perfect, [inaudible] core principles. Every company should have tech that otherwise you’re spending too much time making the code perfect and not enough about features. And in particular, early stage companies should have a lot of it. And all of what makes it so fun is the code quality is contextual, which means earlier stage companies may have achieved the functional requirements, but actually have lower quality code. That’s actually a good thing, not a bad thing. So sometimes it’s just having the explanation ready. We have a traffic light system and it’s a little bit unnerving to see page after page of reds and oranges for higher risk. But once you know it and you can explain it, it goes a lot. It goes a lot easier. And when there’s substantive issues on developer activity or security risks, or unexplained sharp changes in the amount of work, which you’d be surprised how often that comes until it can be explained, sellers have an advantage as well. Yeah, for sure. So COVID, of course, we’ve been doing a lot of work in the spring and we see the COVID dip. In the United States, every single target or a company getting ready for sale had a 25 to 75% decrease in developer activity in February, March or April.
Scott:	Insane. Are you kidding me? I never thought about that.
Matt:	And you can absolutely see it right in the system. And I mean, the data, as one of our targets just said recently, the data doesn’t lie. The question is, what is the context driving it? There’s always also a holiday dip, but now we just saw the COVID dip. It’s not explained discrepancies that are really challenging.
Scott:	Yeah.
Matt:	I’ll tell you one of my favorite stories, we were doing a diligence and it looked like there was about a 20% decrease for about three months in the amount of coding being done relatively close to the acquisition period, which makes everybody nervous of course. SEMA, long story short, in that week, we get permission to analyze the code. We analyze the code, we write up the reports and then we sit down and explain it with our client back to the target. We come from a place of humility and curiosity and of course building code is an amazing, magical thing. And there are always reasons. The question is understanding those reasons. And what does it mean for a potential going forward, for a company to be acquired? So, we’re looking at this company, which had about a 20% decline for about three months and then it picked up and we said, “Guys, help us understand, it looks like…”
Scott:	What happened?
Matt:	Yeah, what happened? Looks like roughly speaking, a 20% decline for three months and, still on zoom these days and the target team looked around and said, “Oh yeah, we took Fridays off for three months as a cost saving measure.” So literally there was a three-month period where it was exactly 20% reduction.
Scott:	That’s amazing.
Matt:	Stories aren’t always perfect. But they lead to that conversation. And again, always grounded in curiosity, I don’t want to, they’re sellers, we tell the truth, buyers we’re here to say we tell the truth and really big picture. About 10% of the deals fall through because there’s major risks in the code and it’s not worth it. That’s on the risk reduction side and then 90% of deals that go through, we take three to 12 months off of integration or value [inaudible 00:00:21:03].
Scott:	Wow. I hadn’t thought of that either. Why is that? Because the buyer understands the code base so well going into it and knows the weaknesses and strengths, or are you giving that report over to the seller and then they’re like, okay, we can fix some of this stuff or we can…?
Matt:	So, imagine you were running a 250 person sales organization and you did not have a CRM and all of a sudden be handed to you and said, make it better, you would know the people to who should be coaches to everyone else. You would know which verticals you should be focusing on to improve. You would know which processes needed to be tighter. It gives you are literally a roadmap to help improve the code, the process, the team that otherwise, takes months, years to build that subject matter expertise.
Scott:	That’s just amazing. Wow. This is super cool. Who’s your ideal customer? Is it like private equity firms, VC firms? Is it consulting firms? You work through the channel? How do you like to work?
Matt:	So, we are truly agnostic about who we work with. With the really important caveat that this report does not work stand alone. That’s an important principle to do right by the craft of software development. You can’t just look at the report and make a decision. So, someone associated with the buyer needs to provide the qualitative assessment. That could be a CTO of a company doing a tuck in. It could be a value creation team or an M and A team. And it definitely could be consultancies. We love working with them where they get to do their best work of client management and the deep dives. And we get to do what we do well, which is the analytics supporting them. So, we really are agnostic about that.
Scott:	That’s amazing. And so, there was a second use case that we were talking about, which was just the third-party software developers and full disclosure, we have a group that we work with, we’ve been very fortunate. I think we got a little bit lucky to be honest with you and just found some great people, but we’ve automated big portions of our accounting work, which saves us so much time. It’s ridiculous. I still can’t believe we did it, but like I told you, I think before I turned the mics on, I don’t really have the skillset to go in there and audit like their code base. And we have some friends and our former CIO Brit will do that occasionally. Shout out to Brit. But I think this is a really interesting idea for people who, because pretty much everyone. At Kruze, we can see what people are spending money on. And almost everyone’s, even if you have a development team you’re working with some third-party folks do to supplement it. I mean, how does that process work?
Matt:	Yeah, you’re exactly right. Besides M and A, the most common use case is helping manage third party development shops. Not unlike SEMA works with buyers and sellers on M and A. We work both with buyers of third-party development services and forward-looking innovative consultancies and global firms. Again, we’re Switzerland again, maybe unlike Switzerland, whoever goes first has a first mover advantage to explain the code, to have the story, frankly, to compare for providers of third-party development shops to compare their own work to previous consultancies because this is all an archeological dig. We can go back seven firms back and point out.
Scott:	Yeah, but I wouldn’t be [inaudible 00:24:27].
Matt:	You can really see, we saw a minute segue on a very tactical topic for the folks really love digging into this. We actually helped a client. A 20-year-old client software company had eight different external software development shops, helping them and we, all of our work, we always do the full history because it helps understand where you’re going even if you’re not working with these firms. And we help point out to them the sixth oldest companies, the one that they’ve worked with 10 years ago was delivering in very low-quality code. It happened that it was a low-cost bid winner and that’s not uncommon when we find situations like this. There’s an amazing miner’s Canary statistic where if you find this out about your third-party shop third-party shop, you should be listening and fix this as soon as possible, you should run away screaming. And that is when we talked about coding and knowing who’s coding some third-party development shops share the login to the version control system. Yes. Oh God is the right [crosstalk 00:25:31].
Scott:	So, you couldn’t scrutinize the individual developers?
Matt:	That’s a secondary effect. The primary effect, it is a massive security breach for no good reason. The analogy we say, it’s like a bank sharing ID’s for their security guards, right? The risk is so high for the cost of a badge. It really is the miner’s Canary. So, if you ever find that, thankfully it’s very rare, you should change firms. Less rare are some other shortcomings of software development shops. And I think the thing that we’re most excited about is it brings a level of metrics and quantitative assessments so that both sides can look together. We said coding is contextual and about if there’s not enough testing, that could be a financial decision. That’s absolutely true. It may even be truer with external shops who are asked to deliver functions under a certain price, et cetera and cut corners on quality.
Scott:	I was going to say because a lot of them get forced into bidding situations where it is the lowest bid. So, I’m sympathetic like for us, we’re not the lowest cost provider. I mean, we’re pretty darn cost effective, but like you could offshore our work to someone for five bucks an hour and get terrible work. But you would think you were, and it’s, again, if there’s no clearinghouse, if there’s no like analytics layer to say like, ‘Hey, that five bucks an hour place is terrible’, you just don’t know if you’re a newbie like me. Have you guys ever thought this is just a crazy idea, one of my best investments when I worked in venture capital was Angie’s list. And they basically had a seal of approval and that seal of approval got pretty big. And so like, have you guys introduced any of that stuff where you have like, Hey, this shop that Scott works with and the shop down the street, there are different grade levels or seals or approval?
Matt:	We haven’t rolled it out formally, but indeed we do. [crosstalk] podcast. So yeah, SEMA has third-party shops, a select number or rigorously screened who not only use our metrics and we’re proud of them, but it’s less about the metrics and it is they commit to a quantitative approach to continuous improvement. Again, everyone listening, think of this analogy. Would you hire an outsourced BDR team that didn’t put their data into a CRM? No, of course not, right? All of it so, it’s the process for a shared conversation to get better.
Scott:	Yeah. I think also what you’re saying is the willingness to look hard at yourself and actually analyze yourself and see if you’re doing a good job is probably half the battle. The good firms are willing to do that and they probably pick up and learn a bunch. But the firms that don’t want to do are the ones you might want to stay away from.
Matt:	There’s some real truth to that. We can certainly say that the folks who’ve passed our test are open and self-critical and eager to use that data to improve themselves. And so that’s why we are so confident recommending them. To answer your question how does it work? Expression, it tastes like chicken is actually is true here. Literally any code anywhere, as long as we have the version control history, we can quickly set it up quickly analyze it. There’s an ongoing dashboard. And then we write a report or our consulting partners write a report.
Scott:	Wow. That’s cool. Well, kudos to you, man. You built a really cool service and a really cool company. I’m really happy. I mean, again, I used to do M and A and we’re knee deep, we have four public company M and A deals happening with Kruze clients right now. So, the level of scrutiny is so high. That’s where my head’s at right now. So, it was perfect timing just to hear about you guys are done. We should probably wrap this up, but can you tell everyone how to reach out to you? Where to go and SEMA’s spelt with an S, S-E-M-A? Can you tell everyone where to find SEMA and how to just maybe it’s LinkedIn, maybe it’s an email how to get a hold of you?
Matt:	Absolutely. So, you can always go to SEMA software. S-E-M-A software.com. Happy to talk to you directly. I am M-V-I Matt van itallie@semasoftware.com. Also let your listeners know, I think I’m allowed to do this. We’re happy to do a free proof of concept. I’m sure many of you were thinking, it sounds like if it works, but does really work? And no better way than to try it with code, you know so, please feel free to reach out. We obviously live and breathe this stuff and thrilled to have more conversations. So please hunt us down.
Scott:	It’s such a perfect, I mean the CRM analogy really works for me too, because I’m embarrassed to say for the first, I mean, Vanessa started Kruze eight years ago and I joined five and a half years ago up until about 18 months ago, we were not using Salesforce. And so, we actually had a Salesforce subscription for many years. We just didn’t use it. It was like buying the Weight Watchers book or something like that. We knew we were smart enough to know we should be doing it. We just weren’t doing it. And so, I just know how much visibility we have in the organization and sales and like, gosh, it’s such a great analogy. Like your GitHub should be plugged into SEMA so you can actually see what’s happening and have that scorecard. It’s really cool.
Matt:	And of course, there’s activation energy in trying out a new process of course, but at least there’s no work. So, you [crosstalk] tomorrow and then you can start figuring out how to use it and change processes, so…
Scott:	That’s way better than Weight Watchers.
Matt:	Scott, thank you so much, it’s been a pleasure.
Scott:	Yeah. Thank you so much for coming by. I really appreciate it. And everyone, check out SEMA software.com. Awesome job, Matt. Thanks.
Matt:	Thank you again.
Singer:	[singing] It’s Kruze Consulting. Founders and Friends with your host Scotty Orn.

Matt Van Itallie on Sema Software's platform that powers technical due diligence for executives and provides tools to find and fix technical debt

Explore podcasts from these experts