Matt Van Itallie is the son of a math teacher and a coder - so this explains why he now uses code as data. He is a proud Boy Scout, making it of course to Eagle Scout and beyond. After being a management consultant, he found his way to ed tech, and fell in love with improving code. Outside of technology, he is married with 3 amazing kids. He likes to run, play ultimate frisbee, and has a wicked cool collection of minor league baseball hats.Sitting a room with the head of Sales, Matt noticed that there were systems like Salesforce that were built to assess the state and future opportunity for business. He then thought, where are these systems for the code itself?This is the creation story of Sema.SponsorsSpeakeasyLinkshttps://www.semasoftware.com/https://www.linkedin.com/in/mvi/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
We made a product that helps understand what's going on in the engineering organization, has so much possible scope. And then the depth you can go down in any functional area, getting deep in Java or deep in JavaScript, is gigantic. And then on top of that, you can overlay going deep in all the components of a modern SaaS system, whether it's notifications or alerting or all of that.
I could have done better. We went a little bit too broad in the first iteration and built, let's say, half versions or partial versions of many things when what we should have done is build full versions of fewer things. My name is Matt Van Italy. I'm the founder and CEO of SEMA.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Six months of moonlighting. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as a group. Total waste of time. The stories you don't read in the headlines.
It's not an easy thing to achieve. Took it off the shelf and dusted it off and tried it again. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on Codestory. I'm your host, Noah Labpart, and today, how Matt Van Italy built a way to assess your code to improve outcomes for everyone involved.
This episode is sponsored by Speakeasy. Grow your API user adoption and improve engineering velocity with friction-free integration experiences. With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolf Pack at QAwolf.com.
Matt Van Italy is the son of a math teacher and a coder, so this explains why he now uses code as data. He's a proud Boy Scout, making it, of course, to Eagle Scout and beyond. After being a management consultant, he found his way to EdTech and fell in love with improving code. But outside of technology, he's married with three amazing kids.
He likes to run, play Ultimate Frisbee, and has a wicked cool collection of minor league baseball hats. Sitting in a room with the head of sales, Matt noticed that there were systems like Salesforce that were built to assess the state and future opportunity for business. He then thought, where are these systems for the code itself? This is the creation story of SEMA.
I was working at a software company and sitting in the C-suite meeting and the chief revenue officer stood up and said, it's time for the weekly update on sales. And boop, pushed a button on Salesforce, the CRM we were using and shared stats and said, and here's how the individual sales team members are doing. Boop, pushed another button on Salesforce.
And that of course, CRMs such as Salesforce is executive insight into sales and the sales function. It's also a salesperson tool and a sales manager tool. But it stands alone as executive insight for the C-suite, for the boards of directors into sales. And we went around the room. This was literally 2013. Went around the room and marketing as HubSpot and Marketo.
And everybody had an executive dashboard, thanks to code, except for code. amazing CTO, had spreadsheets and had qualitative assessment. And we're going to have to do this thing called a refactoring and it's super expensive and you're going to have to really take my word for it. And my head exploded.
If we can build code that helps us understand sales and salespeople, surely we can understand, we can build code that helps us understand code and coders. And so that really was the origin story. I spent a few years researching it and not the recommended path to start a business, but one that made sense for me.
And when I was satisfied I had a good enough technology base, I was very fortunate to meet my co-founder, and we've been doing it for the seven years since. It is hard to summarize code, so we really have spent years making it useful for our first product, making our first product useful across 40-plus languages in a detailed way, and all languages at least to be able to say something about it.
And so that's been a huge part of our journey and that's our code scans product. And then about a year ago, incredibly fortunate that some of our major customers asked us to build something new and there's no more magical way to get to product market fit than being asked, being asked by your customers to build it.
We've also started building and have built a product to help coders and help engineering teams manage how much gen AI code is in their code base. So you can think of it like an ingredients list. How much was Gen AI code? How much was human? How much was a mix? And that has been, you know, just, I say grateful and fortunate a lot, but man, it is true.
Just to be able to work on two really important topics to help improve code, help support coders, help businesses and organizations achieve better outcomes through code is an incredible gift.
So tell me about the MVP. So that first version of the product you built, how long did it take to build and what sort of tools were you using to bring it to life?
Let's really tell the truth here. I probably researched a way to analyze the architecture of code automatically. That probably took two years of reading journal articles. I was making a tech transfer play. I thought that there might be some high quality IP at a university that we could use to build our first product. After that two years, we found something.
I'm proud to say that some great research conducted by a professor from the University of Michigan is still part of our product. Once we had that IP lockdown, I'd say it was about eight months to the first MVP. Over time, SEMA has gotten better and better at building MVPs faster, but probably about eight months from business origination to first product.
Let's stay on that first version of the first product. When building any sort of product, you've got to make certain decisions and trade-off, right? And in those eight months, you... You built it and you were doing research and you were trying to figure out, you know, exactly how you wanted to do it.
And you probably had to make those trade-offs as far as approach or technical debt or how you were going to solve the problem. Tell me about some of those you had to work through and how you coped with the decisions.
So first in terms of the technical debt trade-off, I do actually think we got this one. The more advanced you are on product market fit, the more advanced you are on the state of your business, the the more that non-functional requirements really matter. Up to the major companies, of course, where you really have to get code quality and security and open source risk locked down.
But we really had an intentional approach. One of two of SEMA's five values are scrappiness, which means for us solving for a trade-off of quality and speed, and excellence, which is just optimizing quality. A big part of SEMA is continuously asking questions
in this moment what is the right trade-off between quality and speed and sometimes the answer is just 100 quality and sometimes it's a mix and so certainly from a non-functional requirements side we really de-emphasized that when we were getting the mvp we just needed to get users reacting to it and putting into the market in terms of the functionality itself we made a product that helps understand what's going on in the engineering organization has so much possible scope
And then the depth you can go down in any functional area, getting deep in Java or deep in JavaScript, is gigantic. And then on top of that, you can overlay going deep in all the components of a modern SaaS system, whether it's notifications or alerting or all of that. I could have done better.
We went a little bit too broad in the first iteration and built, let's say, half versions or partial versions of many things. when what we should have done is build full versions of fewer things.
So you mentioned, you know, multiple MVPs. Tell me about the next MVP then. How did you get there? And then tell me about that inception process there.
If the first one took two years, eight months, give or take, the next one to MVP took three months. We got feedback from some customers. This was something they were interested in, did some
basic market research to just double check it wasn't just anecdote and we pulled the trigger and we really had a hyper focused team working on this and working on this exclusively and a certainly relative to our first version extremely pared down set of first requirements so that we could get it up running as fast as possible i could not be more proud of the engineers who worked on it and
Simultaneously, there's a dashboard component that had to be... Engineers are very picky. You got to get it. You got to meet their quality standards. But oh, by the way, we're also detecting AI, which is an incredibly hard problem itself. And both pieces came together absolutely all thanks to our extraordinary engineers in a few months. And we had the MVP up in three months from start.
This episode is sponsored by Speakeasy. Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product.
Shorten the time to live integration and provide a delightful experience for your customers. With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination.
Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag. Visit speakeasy.com slash codestory to get started and generate your first SDK for free. This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API.
With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices. Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators.
Get started for free today by visiting snaptrade.com slash codestory. So let's stay on that second MVP then. You've got the MVP done, you're moving faster, you're getting some traction now. Tell me about how you progressed it from that point and matured it.
I think to wrap that in a box a little bit, what I'm looking for is how did you build your roadmap and how did you go about deciding or still go about deciding this is the next most important thing to build or to address with SEMA?
Well, the third value of ours is growth and And that includes really speaking up if you disagree and including telling me no. I think it's super important for organizations, certainly for SEMA, to be real with each other and to override, including to push back against the CEO. Always confident, but not always right. Someone once said about another CEO, and I'm sure it's true about me.
And so we have really rigorous discussion about what we should prioritize. This is a product for engineers, and so our users... Our engineers who are building it and other engineers at the company definitely have a seat at the table on the roadmap. We are as fanatical as we possibly can be on getting feedback from our customers.
And hopefully we're just on the edge of annoying, maybe slightly past, because what they want goes. Certainly when it comes to how we can make it an incredibly delightful product, it's just not possible to get enough feedback from users. So we spend a ton of time on that. We spent a lot of time on wireframing and writing and showing proofs of concepts before they're even built.
So the scrappiness idea, if we built this, would you care? What problem does it actually solve? And does it actually really matter? Something I've learned in my journey as an early stage product CEO is there are so many different variations of Yes, but almost all of them really are no unless someone's actually going to pay you. Idea sounds great. Oh, that's really interesting. Oh, I'd love it.
Yeah, I could imagine doing it. It's all no until they actually pay and really just being okay to be blunt. Does this matter to you? We think it's interesting. We think it has value. But really, what do you think and why do you think that? We really try to be relentless on understanding the why, the what and the why of what people actually care about.
So I hear you talking about we, and you've mentioned values and, and things of that nature. I'm curious about how you built your team. How did you go about deciding, you know, what did you look for in these people to indicate that they were the winning horses to join you?
Took a little bit of trial and error. The first measure of fit is demonstrated matching with our values, ownership, growth, excellence, scrappiness, and That doesn't mean some people couldn't be awesome in other circumstances, but we head in one direction and that direction is based on our values and folks have to be on board with that.
Second, we are really insistent on following our communication norms. We happen to be a global remote organization, but I frankly would do this even if we're all sitting in the same building. That means in practice that we are intentional about how we communicate, that we communicate about how we communicate, and that we know what our colleagues' preferences are.
You can't always be communicated with like you'd prefer, but we should at least know what our communication preferences are. So if we're not following someone else's, we're wearing them down rather than adding more energy. After that, I'd say demonstrated evidence of excellence in their field really matters. And then after that,
demonstrated experience in startups as everybody listening to this must know there are very different feelings for very different stages of an organization's life and some people can be wildly successful at different stages but you have to find courses for courses that match the stage that you're in especially in the products that are at the product market fit phase that kind of
mentality is different from rapid growth. It's different from an organization that needs to stay excellent. It's different from turnaround. And it's been a very long time since we've hired someone who hasn't recently worked in a startup.
This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf. QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes.
With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs? Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. This message is sponsored by SnapTrade.
Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This will be super interesting. Given who you're serving with your product, I'm curious about scalability, right? Did you build this to scale from day one or with scale in mind?
Or has there been interesting areas where you've had to fight it as you've grown?
Definitely fighting it as we've grown. If you are driving a stick shift, Google it if you don't know what a stick shift is, listeners. And you don't stall. That means you're riding the clutch too hard. You don't stall, at least occasionally. If you extrapolate it slightly, if you don't find yourself in pain points, at least sometimes, that means you have over-engineered it from the beginning.
And I definitely believe that about product scalability. So many things... can feel like the right thing to do. They feel right, man. You just feel like it's a sense of accomplishment. But if you are not getting to product market fit, if you are not getting growth, if you're not getting a feature adoption, nothing else matters.
I think we've done a really quite a good job of being rigorous for the products that are at the earliest stage and features that are at the earliest stage. When we we do a very comprehensive code scan and when we are building a new version of that piece of functionality, a new module, we hand create it.
We run the analytics, produce a CSV and build it by hand, usually for a month or two, because that's, of course, not at all scalable. Number one, it saves a huge amount of engineering time. And number two, you really have to be sure you're building the right thing.
And it's a mark of success for us that we run into scalability issues that then need to be solved with better, with a different architecture, different engineering approach, etc. The absence of running into scale issues would itself be worrisome for us.
Okay, let's move forward then. So as you step out on the balcony and you look across all that you've built with SEMA, what are you most proud of?
The team and the trust-based relationships with our customers and partners. The team side, I just could not be more proud that folks, most of whom we've never met, we are a global team and have really come together to have one and one equal three or more. So many different backgrounds, so many different experiences, but all marching in the same direction to build something that matters.
And then what we do, as we say in our work, the code of a company is the second most important thing they have after the people. And we've had a trillion dollars of organizations trust us to scan their code. And that is such an honor from our clients or our partners to code owners, because we frequently are involved in technical due diligence.
That is just an unbelievable statement of trust that we work every day to earn and re-earn. I am just so proud of the team for building something that matters enough and has earned the trust of organizations like the ones that we serve.
Okay, let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
The mistake that comes foremost to mind is a product roadmap decision that I made with I directed the team, guided the team to build more of a robust set of functionality than really was necessary to get to product market fit. We were going too broad when we should have gone deeper. The evidence of that was in the growth rate of the first product, which is to say it was not growing enough.
And the solution was to radically simplify. We basically lopped off a big chunk of that product just so we could focus on a core part that we were pretty sure customers would really value. Thankfully, it turns out we were right, then continued to build that product, that CodeScan's product, based on a much smaller but much firmer foundation than what we'd initially been building.
This will be super interesting. I can tell the passion you have for the product you've built and for the folks you're serving. I'm curious what the future looks like. So tell me about the future for SEMA, for the product and for your team.
The work on code scans continues to evolve. That original North Star question, how can we help CTOs have a clear picture of what's going on in engineering? There's a lot in that. There's a lot of engineering functions. And over time, we're adding more and more of them. We are simultaneously making the system more performant and more scalable, which is, of course, when it's the right time.
It's so fun to work on that. And our product is 100 times better and 100 times faster than when we started, probably more than that. And that is such a cool trend, which will continue.
We are, on the code scan side, we are well on our way to really creating a language to help engineering decision makers, including boards of directors and CTOs in the C-suite, have a common language to understand how to make investments in code. And one of the ways we do that, frankly, is through
It's just a numbering system we've built after many years of collecting data and trying to be as rigorous as we can. We built a 1 to 100 score of non-functional requirements, or we call it code base health. And it's really accurate. If you're a 30, your code base is a lot riskier than if you're a 70. And we can say why, et cetera.
And seeing that vocabulary permeate across some of the, frankly, the world's best software acquirers and operators is... It's an awesome feeling and it's only going to continue. So that's on the code base scan.
The need to manage how engineering teams are using GenAI to code and how to make sure that they're using it safely and responsibly, of course, has exploded and will just keep growing at an exponential rate. And the opportunity there to really do well by everyone. It is better for organizations to manage GenAI codage safely.
It's also better for end users, and it's better for the developers, because one of the ways that you make GenAI code safe is by making sure that there's always a human in the loop. This isn't about automating away engineering jobs. This is about helping engineers be even more turbocharged and superpowered than they were before, like open source.
And frankly, there's a growing global need for managing Gen-AI usage that is so awesome to be, frankly, leading the way on. And then finally, team. We grow. We're growing as our business grows and continuing to find excellent people and protect our culture and protect our communication.
as the team expands is not a small task, but it's a really joyous one because the end result is there's just nothing, nothing more satisfying than waking up and going to work with people that you can be real with and trust and are building something excellent together.
Well, Matt, let's switch to you. Who influences the way that you work? I'm a person or many persons or something you look up to and why?
I try pretty hard to be open to learning from everyone. I was an upright bass player, the one larger than the cello. I played in orchestras in high school. Those of you who don't know this, I'll let you in on a secret. To play in an orchestra as a violinist, you have to be really good.
To play in an orchestra with a double bass, you have to have a car big enough to carry a double bass, and you have to have a double bass. The quality standards for double basses was way lower than the much harder working violinists and cellists and violists. And so I got to play way above my pay grade in youth orchestras. And I remember playing with a bassist who was genuinely extremely good.
And she seemed like she was paying attention to what I was doing. And I said, why, what are you like, come on, you're so much better than me. And she said, I really try hard to learn from everybody. That has really stuck with me of trying to see positive lessons from folks and also negative lessons.
Sometimes the negative ones, oh, I'm not going to do that again, can be more clear, but that's the general point. More specifically, I could not be more lucky for our board of directors, just absolutely spectacular guides who hold up the mirror, tell us the truth, keep us accountable, just hit the jackpot on an incredible board of directors.
The leadership team, the engineers, product folks, everybody, like they tell me the truth. I think I've learned at least one thing from each colleague in the last 12 months. That's an amazing feeling. I learned a lot from my kids, from my wife. And of course, really lucky to have had really great teachers along the way. And the ones that stick out are the ones who set the highest standards.
Shout out to Bob Weinberg, who, college professor, who walked out on our class because we hadn't done enough of the reading because he said we could do better. And what a statement of high expectations and looking to us to be the best version of ourselves and Bob's one particular example, but I've been so fortunate to have great formal and informal teachers along the way.
Last question, Matt. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and they can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
I would say I'm happy to look at it, but unless I'm your ideal customer profile, your ICP, it doesn't matter what I think. Or unless I'm about to write you a check, it doesn't matter what I think. The real trick of early-stage entrepreneurship is to be maniacally focused on a tiny number of things that include not running out of money. That's number one.
Number two, delighting a very particular ICP and spending all of your energy understanding what it's going to take to delight them and making sure your organization is carrying out what it will take to delight them. And pretty much everything else...
you should forget about even if you're like quote not doing a good job unquote on other areas you just have to get that kernel once you've gotten that kernel then how do you continue that rate of really making delighting customers and users and then start adding the rest of the parts of the business the systems and structures that will help you continue to grow.
Generally speaking, if I ran into an entrepreneur, hunches, they're only going to be able to do a small subset of all of the functions necessary. And so the faster they can understand themselves, what they're good at, what they like doing, the more likely it is that they can fill in the gaps with a team that help the company really thrive. But all of that, it's just so fun and so interesting.
It's not a substitute, just getting the product market fit and then growing it and All these things that feel like accomplishment, it's not. Just build the right thing with a critical eye, but build the right thing, and everything else will follow later. I wish I had done literally one-tenth of the functions or activities that I worried about when I got started.
It's easy to say be focused, but you just don't know how focused you need to be until you've lived it.
I think that's fantastic advice. Well, Matt, thank you for being on the show today, and thank you for telling the creation story of SEMA.
Thank you so much for having me. It was an absolute blast.
And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.