Trilogy Search Series Ep.5: Kevin Knoepp and Zach Seely

Live Oak Bank — Live Oak Bank is a seasoned SMB lender providing SBA and conventional financing for search funds, independent sponsors, private equity firms, and individuals looking to acquire lower middle-market companies. Live Oak has closed billions of dollars in SBA financing and is actively looking to help more small company investors across the country. If you are in the process of acquiring a company or thinking about starting a search, contact Lisa Forrest or Heather Endresen directly to start a conversation or go to www.liveoakbank.com/think.

Hood & Strong, LLP — Hood & Strong is a CPA firm with a long history of working with search funds and private equity firms on diligence, assurance, tax services, and more. Hood & Strong is highly skilled in working with search funds, providing quality of earnings and due diligence services during the search, along with assurance and tax services post-acquisition. They offer a unique way to approach acquisition diligence and manage costs effectively. To learn more about how Hood & Strong can help your search, acquisition, and beyond, please email one of their partners Jerry Zhou at [email protected]. 

Oberle Risk Strategies– Oberle is the leading specialty insurance brokerage catering to search funds and the broader ETA community, providing complimentary due diligence assessments of the target company’s commercial insurance and employee benefits programs. Over the past decade, August Felker and his team have engaged with hundreds of searchers to provide due diligence and ultimately place the most competitive insurance program at closing. Given August’s experience as a searcher himself, he and his team understand all that goes into buying a business and pride themselves on making the insurance portion of closing seamless and hassle-free.

If you are under LOI, please reach out to August to learn more about how Oberle can help with insurance due diligence at oberle-risk.com. Or reach out to August directly at [email protected].

Interested in sponsoring?

(4:00) – Zach’s experience at FSI at the acquisition point

(6:05) – Zach’s skills background & where Kevin fit into FSI

(7:34) – Kevin’s process for analyzing the technical side of software businesses

(10:50) – What are some red flags you’ll see in diligence?

(12:22) – What’s your perspective on Technical Debt?

(15:03) – How did you structure your deals or build teams to adjust for technical challenges you found?

(17:03) – How did you first set your priorities for what to fix with FSI?

(22:22) – What are some must fixes before you can complete an acquisition?

(23:52) – What sorts of gaps did you focus on in the first 18 months at FSI?

(26:54) – How did you evaluate the technical team before the acquisition?

(28:12) – What kinds of questions do you ask the technical teams to assess their abilities?

(31:46) – How do you evaluate and mitigate risk on a technical team?

(36:46) – What 2 to 3 changes did you make to the technical team right off the bat?

(41:59) – What sorts of processes have you set up to make work more transparent?

(45:11) – What are your thoughts on outsourcing vs. insourcing tasks or positions?

(49:19) – Is it common for software companies to offer some sort of budget for outsourcing services to their developers?

(51:27) – How do you evaluate if your team is utilizing capacity properly?

(54:34) – How did you evaluate FSI’s pricing strategy?

(57:15) – What common parts of a pricing strategy could use the most improvement in software businesses?

(59:19) – What strongly held belief have you changed your mind on?

(1:01:30) – What’s the best business you’ve ever seen?

Alex Bridgeman: It’s good to see you both on the podcast. I’m glad Aaron was able to introduce us. Zack, I think a good place to start to kick off the episode is to hear about your FSI experience starting at the acquisition point. It sounds like it was a deal you kind of came in while it was in progress. And I’d love to hear about how that came together and then how Kevin got looped into due diligence and technical analysis and all this other stuff. But I would love to start with the acquisition point and go from there.

Zach Seely: Sure. So FSI is a SaaS business focused on the healthcare space. We serve hospitals across the US along managed maintenance asset and work order management. It’s a 20-year-old business founded and run by a single individual with a lot of background in the manage maintenance space within health care. And that’s right, I came into it kind of midstream, but what was really exciting was this was a business with exceptional product market fit. It had been in business, had a long track record, had been in business for 20 years and had a growing customer base and was sort of poised to grow and scale in a way that just was not the strategic focus of the business in the past under the owner and operator. And there were a number of market dynamics that also could have made it very interesting and exciting. But I came into it, I was introduced to the founder and to, early on, about six months before we closed, the actual acquisition. And we had signed an LOI outlining the general terms and were quickly moving forward with due diligence to really understand everything from quality of earnings and marketing to the technology and kind of everything in between. And along that process, I was introduced to Kevin, who works closely with one of my main investors in this acquisition to help better understand the technology, the tech team, and where there could be potential strengths and gaps along those dimensions.

Alex Bridgeman: So, in looking at the due diligence picture for FSI, it sounds like there’s a lot of probably commonalities across companies from a wide variety of industries in terms of examining organizational structure, finances, marketing plans. But the technical side can become very specific and very detail oriented. I would love to hear how you incorporated Kevin into that process. And what does that diligence look like from a very technical perspective?

Zach Seely: I’ll let Kevin dive into kind of the deeper technical aspect. My background is in technology but from a business standpoint – I don’t have an engineering degree or haven’t worked within product organizations or anything like that. And so, Kevin really led our technical due diligence across the board. I’d say at the highest level, what we really wanted to understand was where the gaps potentially were in the product, how long term scalable it was, level of tech debt that we had. And then on the other side, what did the technology and product leadership look like? What were the strengths and capabilities of the team, the dynamics of the team? And what would we need to worry about across both those dimensions on day one, never mind kind of day one thousand, of acquiring the business and operating it?

Alex Bridgeman: Kevin, I think it would be helpful to, prior to diving into FSI, just outlining your general process for examining the technical side of software companies. What does that process from end to end look like for you? And then how did you take that process and apply it to FSI?

Kevin Knoepp: Yeah, we usually start out with just a tech diligence questionnaire that covers about ten aspects of a diligence. So, we want to talk about the team, the product, its design and architecture, about scalability, about security, talking about the code base, the code quality, organization, comments, the database and data structures, the general software development lifecycle, how did they actually build their software, the implementation process, how hard is it to kind of get the software out there, how is project management done, who decides what gets built, and finally, and we talk about the IP. What have they got in terms of patents or has everything been properly assigned? So, I sent out just a questionnaire for the technical team at the target company to answer. And then we’ll get together and do usually a one to two hour walkthrough of their answers. And assuming the company is not actually hiding anything, and they’ve been forthright and verbose in their answer, usually at that point in that initial phone call, I’ve got a pretty good idea if these people know what they’re doing, if they know how to write software, if they’re on a modern stack, and have a good team. So usually after that, I have a pretty good idea to share with the searchers that this is looking pretty good, or no, run away from these guys at this point. And that’s rare, but I have had a few where it was like don’t touch these people with a 10-foot pole. So, we’ll do that. And usually about at that point, I can give a pretty good idea of like a statement of work of how long I think the diligence might take and how many things I’m going to need to deep dive on. And then I do a really, really thorough, and sometimes this is multiple hours, demo of the product. You really can’t go too deep on a product until you’ve seen like every corner of it and get a really good sense of how it works. And after the demo, it’s just a series of deep dives with the idea that we’re just verifying what they actually shared in the initial questionnaire and like any other skeletons buried that they didn’t bring up. And it used to be I would go on site; pre-COVID, I would go on site and do most of those in conference rooms and meet everybody in conference rooms. Nowadays, it’s Zoom for the most part, like everything else in business. And I’ll audit what I can get access to. As Zack mentioned, there are companies that are real cagey about giving me access to source code or allowing me to even have direct access to the application unfettered. So, I’ll do whatever audits I can of the code and the environment. And then finally, I usually, and Trilogy now, who I work with most, is doing this almost every deal is we will set up a full security audit. I’m not personally a security professional. So, we’ll set up a full security audit penetration test with people that really know what they’re doing. And that’s kind of how it plays out.

Alex Bridgeman: What are the most common reasons that you’ll go back to searchers and say don’t touch this company with a 10 foot pole? What turns companies away the most?

Kevin Knoepp: Okay, well, usually, it’s around the software development lifecycle. I’ve had a lot more companies than you would think that like they didn’t believe in source code control. I had one company that had 70 servers serving their customers, and the way they wrote software was they would literally log into the server and, in real time, type around making changes for a given customer with like no source control whatsoever. And it’s like, that kind of thing is really, really hard to get over. Once in a while, it’s a product is built in a language that is no longer supported, and it’s going to be really hard to find people that can develop in it. So, sort of the tech stack choices. One of the funniest ones where I said to walk away was like it turned out the company that was selling didn’t actually own the software. They had hired contractors to build them, contract was never assigned the software. And it’s like, you’re not buying what you think you’re buying here. So, things like that. Some companies are a bit of a house of cards. And it’s a little bit binary because there are deals out there where the deal is the technology, and there’s a lot of deals out there where the deal is really not the technology, it’s just sort of like a supporting piece of the deal. And if it’s a great business that just happens to have pretty poorly executed software, that can be fixed. If it’s a software business, and it’s really poorly designed and executed, that’s really hard to fix.

Alex Bridgeman: Yeah. What’s your perspective on technical debt? And when looking at FSI, what sorts of technical debt or challenges broadly did you encounter?

Kevin Knoepp: Actually, FSI was one of the better companies I’ve evaluated. They knew what they were doing. They had chosen pretty good modern stack. The software development lifecycle was quite good, they had quite a good team there. The only things really, I think, if I can remember, I should have reread my report for them, I remember that they were very light on testing, which we see on almost every search deal I do. And being light on testing is a lot of work because it is one of the keys to hitting really good velocity and sort of being a world class engineering environment. So, getting caught up and getting caught up on testing and testing infrastructure. I think they were a little bit light on automation in general. A lot of things were still being kind of pushed around manually in there, which, again, is not unusual in companies that have been running for a while. So, for the most part, I think they were actually pretty good. The vast majority of the deals, in fact, every deal- FSA, like I said, was at the top. There was only like one other company I’ve ever looked at that didn’t have like a lot of technical debt. And usually, a lot of these businesses, they’ve been around a long time. So, you’ll find companies that have been writing their software for 20 years, 10 years. And what was the best way to write software and the best tooling from 10 to 20 years ago is not necessarily how you want to be doing it today. So, a lot of times, it’s just something you have to get in there and deal with. And it’s just kind of a part of life and buying companies that are going concerns, at least.

Zach Seely: I remember Kevin’s report and our discussions through the process on the due diligence side, and one thing actually that gave me the most confidence is Kevin’s feedback around the team culture and the team dynamics and knowing that, listen, there’s always going to be tech debt, there’s always going to be competing priorities. It’s important to have good processes, you can always mature those processes, and in evolving company and industry landscape, you’re going to have to make a lot of changes regardless. But knowing that we were in a good spot was great. But what gave me the most confidence was this was a team that worked well together, liked working with each other, in many cases, had been working with each other for a long time. And that sort of organizational dynamic was super important to me to have a lot of trust and confidence that whatever gaps and challenges, priorities that we had to wrestle with moving forward, we could tackle those because we had a lot of the right people in place.

Alex Bridgeman: And so, when looking at the different technical challenges that FSI was encountering, what did you do in terms of either structuring your deal or, after acquiring, building a team, what sorts of things did you do to adjust for those challenges?

Zach Seely: In terms of structuring the particular deal, like Kevin said, FSI was in a relatively mature state, so there weren’t a ton of gaps that really needed to be addressed from a deal points perspective. So, with that said, it didn’t come into the sort of negotiations in a significant way at all. Since taking over and operating the company, things changed a lot. We’ve changed out our development leader. We have expanded the team quite a bit. And you’re always going to wrestle with competing priorities on the development side. And that’s one thing that I kind of had fooled myself that we were in a really mature spot, that we’ve kind of gotten this figured out. Every company across the spectrum deals with having more work than the team is able to execute on and really having to make really hard decisions. I’d say, one of the pieces of confidence that I had in this team and in what they were doing was it actually wasn’t my first priority to make a lot of changes early on. My time and focus was really steered towards sales and marketing and building up other parts of the organization that weren’t as mature. But we’re actually going through a really exciting process right now to restate and redefine our product vision and strategy and think about team organization and dynamics in order to execute along that. And so, it’s come back full circle. And after we kind of solve these problems, we’ll go on and look at the next opportunity within the organization to keep moving forward and maturing.

Alex Bridgeman: And how did you, when you were looking at the different projects from a technical perspective that FSI needed to work on, some being product improvements, some being legacy improvements or technical debt resolve, how did you make the decision which project to choose? What was your process for thinking through the right priority to focus on? And then, Kevin, after Zack shares, I’d love to hear how you view the two technical debt and product development and what you advise searchers do for the most part. But Zack, I would love to hear the FSI perspective.

Zach Seely: One of the most helpful things coming out of actually the due diligence is Kevin’s report on not just the state but also what he thought the priorities would be once I stepped into the operating role. And things around security and performance immediately go up on the list. And so those are areas that we tackled and where we had kind of outstanding questions from the acquisition and due diligence phase. Those were areas that we immediately devoted resources or brought in outside consultants to help us tackle. So that was kind of the immediate push. In the first sort of 100 days, six months of the acquisition, it was really around, first of all, not breaking anything, not making too many dramatic product or other sorts of changes that were going to kind of take us out of our steady state and business as usual. So really thinking around tech debt and other incremental improvements that we can make. And then with more experience, really having a better understanding, a lot more discussions with current and future customers, understanding the sales cycle, et cetera, we started to weave in more future development priorities into our product roadmap. And that prioritization matrix and how we sort those things out is still something in flux that we’re thinking a lot about and how we continue to try and make the best decisions and organize a company and organize our teams in order to execute around those priorities.

Kevin Knoepp: Yeah, I think it’s all a matter of the degree. There have been companies out there where, literally, if we didn’t fix the system fairly soon, it was going to collapse. And I think there are a subset of sellers out there that like they’re selling because they know they built a house of cards, and they want to get out of it. And there are places where you don’t want to take that on. And there’s places where it’s like, yeah, this is not scaling, that’s not great, but it’s fixable. We get in and look at how. So it’s all a degree of- it’s all a matter of degree of how bad things are. Are we just looking at out of date development tools? Are we looking at a really bad code base, like we talked about earlier? What’s their testing? What’s their focus on security, documentation, automation, things like that? A related thing is it’s fairly common in search deals to have a situation where the founder or a couple of founders themselves wrote the code, and they’re now selling because they want to go and like have a life. And so how do we quickly get the one or two experts in this entire infrastructure, get all that knowledge transferred over to other people? We also see a lot of kind of very wacky hosting environments, which can add an extra layer of complexity of their either on-premise software or they have a very boutique hosting environment. So, you’ve got a lot of pieces that you have to get in there and move at once. And there’s a great thought leader in software development named Martin Fowler, and he coined a concept called the strangler fig tree pattern, which is based on like a tree in Australia, where a fig tree just grows on the original tree. And over years and years and years, it like kills the tree inside, and it’s now its own tree. So, one of the things that we look at when we’re looking at how are we going to deal with tech debt and get these code bases kind of shored up is can we carve off pieces of the original system and replace individual parts of it one at a time in kind of a long rolling rewrite, a long rolling refactor. It’s almost always a terrible idea to say, oh, let’s just come in and rewrite this system from scratch. You want to look at like little pieces you can pull off, and we can fix this module, maybe it’s not performing well, we can fix that module in isolation of all the others. So, it’s a matter of how much degree you have. I mean, we always want new features and to push things forward. But technical debt is kind of like the shortcuts that you took to get where you are now that’s really kind of blocking you from being able to hit a good velocity on these new features. And sooner or later, you do have to address it. So, you can’t hide from it, unless you have- I have seen a couple of deals where the software was not great, but all the team really wanted to do was increase the market share without adding a whole lot of features. So, all we really had to think to do is like how do we make this scale, rather than, how do we fix everything. So, I think it’s all pretty dependent on what the driving forces for wanting to close this deal are.

Alex Bridgeman: And when you’re looking at these software companies, what sorts of things need to be addressed before an acquisition is made that can’t wait and maybe are less fixable and need to be addressed and discussed?

Kevin Knoepp: I haven’t seen a lot of sellers that actually wanted to do a whole lot before a deal would close. If we find that they have not had any sort of a security component of their software development lifecycle, we will almost always say we need a security audit pending closure. Because if they just haven’t paid attention, the last thing in the world you want to do is to put up a bunch of money for a company, and two weeks later, they’re ransomwared or they’ve been hacked. So often we will make a security audit a condition of closing, unless they recently had one from a reputable firm that really went through their system in detail. Just as a side thing, we were talking about IP and having full assignments, obviously you can’t close the deal until you’re sure that everybody that’s worked on the software has fully assigned their IP rights and any contractors that you’re using are work for hire and that you own the software. So those are sort of the main things. I haven’t had anything else where I’ve come in and said, change the way you’re running the business and demonstrate that you can do that before we’re ready to close this deal. If there’s things that are that important, usually it’ll be a blocker to proceeding on the deal anyway.

Alex Bridgeman: And Zach, you kind of alluded a little bit to it, but oftentimes, there are organizational gaps that need to be filled over time, maybe not immediately day one. But when you came into FSI and looked at the team you had, what sorts of gaps did you feel like you could improve on and needed to be a focus that first kind of year, year and a half or so?

Zach Seely: Absolutely. What’s interesting is those gaps may not be apparent in the sort of current structure because oftentimes when you make the acquisition, your goals and strategy may change or shift or evolve. And so, the gaps may kind of evolve, or you may uncover those gaps over time. With FSI, we knew just from a sales and marketing standpoint, especially on the leadership side, that was a huge area that we needed to invest in. And for a lot of good reasons, it wasn’t the primary focus of the founder’s dollar investment. He was really good at sales and marketing. So, he just did a lot of that work himself. But he hadn’t built a deep bench strength in sales and marketing, and they had devoted a lot of resources, especially on the marketing side. So right off the bat, we knew we needed to do that and spend our time there. The other area of focus wasn’t quite on the organizational side, but it was on the internal tools and software side. We used our own what’s called CMMS, computerized management maintenance software, as our CRM, as our development tracking tool, as our customer support tool, in some cases, as our ERP, et cetera. There’s kind of a nice thing about eating your own dog food, as the expression goes. There’s also something about using non purpose-built software to run a lot of disparate internal processes and just departments and functions and that sort of thing. And so that was a huge area of focus that basically touched every single team, was rolling out purpose-built software and tools in order to help facilitate that scale. And that’s something that Kevin and I talked about quite a bit as our dev team used our product as their development tracking tools without kind of the quintessential development metrics and process and other elements that are kind of table stakes. And just one other interesting aspect about that, even if you find a way to make it work, it wasn’t purpose built for that role, so we were obviously missing something. It’s also really hard or awkward to recruit people when they ask kind of what development software we use and how we track that and what metrics were we looking at, and we kind of had to tell them a story about how we used our own software and why we did and why we continue to do it, et cetera. So that was a big gap that we recognized early on and an area that took 12 months or more to really mature and change across the different levels of the organization.

Alex Bridgeman: And how did you go about evaluating the technical team at FSI from prior to close where maybe your contact with the team is much more limited, of course, before acquiring the company?

Zach Seely: Yeah, so in our case, we didn’t have sort of full access to the team. We used Kevin not just to perform the due diligence, but to sort of meet the team under kind of the guise of an insurance audit, I think is kind of how we went about it. Obviously, with the full buy in of the seller. And that’s how we kind of went through it. So, I relied on Kevin’s discussions and evaluation of the team. Again, he came back with a lot of positive things to say not just about the individuals that he had met, but also about the team dynamics, which, again, gave me a lot of confidence and excitement around that. And then after we closed the acquisition, trying to put in both sort of hard quantitative metrics in place across the entire organization, not just around development, to really understand productivity and effectiveness and those types of things and rely on team leaders to make sure that they felt that they had the best team that they needed to execute around our strategic goals.

Alex Bridgeman: Kevin, what kind of questions do you ask folks on the technical teams to evaluate just raw talent and then ability to make the improvements that you think are important for that company to make over the coming years?

Kevin Knoepp: Yeah, FSI was unusual in that they did have a very good engineering leader who sort of like knew how to write software and run the software team. So, that one was easier than a lot of them. Now, in that particular case, I didn’t get an opportunity to interview all the different members of the team because the seller wanted to keep this much more private. So, I spent a lot of time with their engineering leader and a couple other people that I did have access to kind of cross referencing, walking through the members of the team. So, when I do have full access, what I like to focus on is the skill set, kind of how siloed are the individuals and what’s their skill set, talk a lot about morale, and which ones might be a flight risk, and focus on how can we kind of do this transition without spooking anybody and losing anybody in a regrettable attrition. One of the things that I often look for, for software engineers, is a lot of times in search deals, specifically, you have people that have been very insular, they’ve been the developer for that company, and I’ll see quite often 8, 10, 12 years, which is crazy long in most software companies, and they have gotten very, very comfortable. And if I talk about, well, how do you like keep up with the market and keep up with tech? They don’t. And it’s evidenced by the fact that they’re running on like an ancient version of PHP, or they’re running coding in Visual Basic or some really archaic language. So, I do look for the ones that get out. I’ll ask about, and again, pre-COVID, this was a bigger indicator, do you go out to meet ups? Do you do professional development organizations? How do you keep up with kind of changes in software development life cycles and just try and figure out if they see software engineering as a craft and they’re the kind of people that are reading technical blogs and going to meetups, virtual or in person, try and get a real good sense of the individuals and which ones with good mentoring could quickly learn how to do the things they haven’t been doing, and we can level them all up, versus the ones that are just kind of set in their ways. And then, another interesting indicator is always the diversity. If it’s a bunch of very similar doofussy old white guys like me, it’s probably a more insular environment than if they have a diverse team. They’re not out kind of competing. Search deals do have a bit of a handicap in that they rarely will have really good employee stock option plans. So, you have to also filter for the fact that the packages that a search deal, for example, can offer right out of the gate may be less kind of appealing to sort of world class engineers out there. But those are mostly the things I look at, as well as if I have full access, you can look at their pole requests, and whatever their source code tool is or their contributions to the overall code base and get a good sense of like this person seems to be doing 80% of the work, and these three are doing the other 20, what’s going on here?

Alex Bridgeman: Yeah, how do you evaluate the key technical or key engineer risk, where maybe there’s one person in particular who was instrumental in one module or one crucial piece of your software? How do you kind of evaluate where that risk lies, and then mitigating it through training the rest of the team or helping that person share or something else? How do you go about looking for that answer?

Kevin Knoepp: Yeah, the danger and what I do see a lot is when the developers are the founders, and they’ve also been sort of like gatekeepers. They really don’t share. I’ve seen some deals where so and so wrote the entire system and is one of the owners or the founders, and they’ve been a one person band the whole time. So, at that point, it’s a matter of how quickly could we get an equivalently senior person into the organization and start doing cross training? And what’s sort of the engineer who’s like holding on to all of the key pieces of code, what’s his or her motivations to let somebody in and help? Are they going to, post close, are they still going to drag their feet about that? So it is something that you really have to balance out. I think every software company has problems with kind of knowledge concentration. So, it’s not necessarily unique to this space at all. But immediately looking at, again, this is one of the things we’re looking at where we’re looking at the skill sets – okay, these people only have one front end developer, and of course, that person’s done all of the front-end work. So now we’ve got to figure out how to de-risk being set on that person, or if there’s only one sort of person that’s doing database work, and nobody else knows how to do it. So, a lot of it is just de-risking. And I think one of the things that we need to look at as we’re closing is like a real gut check on who’s a flight risk and how big of a problem is this likely to be. Companies do bandy around kind of like we’re a family, we have kind of a family culture here. They were one where it was pretty clear that that was a bunch of people that really liked working together and through the transition was not going to be a bunch of people just getting spooked and taking off. One problem we have is that quite often the engineering leadership team in a given company is really not up to kind of taking that company to the next level. A lot of people are buying a company and they say, oh, this is really, really interesting. And I’m going to drop in, and I’m awesome. And I’m going to like pour gasoline on the fire, and we’re going to just blow this thing up. Well, if you’re buying a company that’s been underperforming up to this point, and that’s one of the things that makes it an appealing deal, to think that just because an MBA shows up, suddenly the engineering team is going to know what to do that day is a bad plan. So quite often, we do have to immediately start thinking about bringing in an engineering manager that actually knows how to write software. And it has to be someone with a very, very high EQ because you definitely do not want to spook the engineering team with like here comes a really big culture change, and now there’s a new sheriff in town. So, trying to get somebody on board. And it’s a little bit binary. I find with teams, teams break down two different ways. One way they break down is a very, very insular group, and they’ve been doing it this way forever, and they’re very comfortable in their ten to four, drop in, do some coding, call it a night kind of cycle, and don’t really see a need to change, don’t understand the value in things like automation and tests and a lot of modern software practices. And the other one, the other thing that I see a lot is teams that are really, really hungry to know how to do it all right. They’ve never had any, maybe they haven’t had any process up to now. They’re just kind of throwing stuff against the wall and seeing what sticks. And you come in and say, we’re going to put these processes in and we’re going to start using bug tracking software, we’re going to try and start tracking our work, we’re going to start writing tests. In some cases, they’re not doing any variation of Agile or Scrum or Kanban or XP or whatever model fits their team size and team composition well. And quite often, we put it in there, and they’re like, this is awesome, I finally know what I’m supposed to be working on, I finally know that these are the metrics I’m going to be measured on, I can finally understand where the product is going and what we’re going to work on next. So, if you find a first case, you almost always have to figure out a way to drop some senior developers in there along with new engineering management. The second case, it might just be an engineering manager or Scrum Master, get some people in that kind of can just like steer the people and kind of level up from the inside.

Alex Bridgeman: And, Zack, when you were getting into the business, what two to three decisions and changes did you make on the technical team to start organizing and getting that team prepared to make further changes and growth with the system?

Zach Seely: A couple of things come to mind. One is just around work intake and making sure that the process is broadly understood both within the development team but also across the rest of the organization. Kind of being a sort of smaller software company, even one that had grown quite a bit over its time, there was this feeling where I’ve worked with this person for a long time. So, when I’ve got a question, I’m going to tap them on the shoulder and kind of disrupt what they’re doing and ask them to do me this favor in a way and on something, or can you look at this, et cetera. And it exacerbated a lot of other challenges and competing priorities for our development team. And so making sure that we had the right work intake, which not only streamlines the process and makes sure that there’s prioritization steps and there isn’t a ton of context switching and other sort of traditional work waste type behaviors, but it also allows you to track and show over time how that is changing, increasing, decreasing, whatever, staying the same, which helps give evidence for what people are already feeling. And so, making sure that we had a data component to managing either frustrations or challenges and those types of things. Like the primary area that comes to mind is really around work intake. The second thing, and something that we’re still trying to do and trying to expand, is getting everybody, but certainly it applies to the development team, out of the development team for a little while. I mean, everybody works in collaboration with everybody else or with a lot of other teams, and especially in this remote first environment, and FSI was remote prior to the pandemic, so we’ve been dealing with kind of the challenge of not being co-located for quite a long time. But too often, while you’re trading work back and forth or asking questions on an email and getting part of a response, et cetera, there is just really limited understanding and appreciation of what your colleagues are doing and the frustrations that they have or how they’re wrestling with other factors that you’re not seeing firsthand. And so, making sure that our team and certainly the development team, especially with some of the folks around support and level two support and even the sales cycle, our development team is getting that exposure, sitting with those other groups in order to both develop stronger bonds with their colleagues, to get a better appreciation of customer questions or issues or challenges, and to build just more general awareness is super important. We’ve got a developer who just started this week, and they’re spending all of their second week shadowing support in order to just get a better sense of the questions that come in, the challenges that are coming in, and those sorts of things. So that cross pollination is something that I think is especially challenging in this remote first environment that most companies, I’m sure, are wrestling with. It’s an area that every time we’ve made a decision to make a little bit of progress, it’s actually been quite profound as to the excitement, interest, and I’m not sure the right word, it’s sort of like there’s just a general acceptance of there’s more to kind of the issues that everybody faces than just what we see in our day-to-day job. One of my favorite stories is we had our Agile manager, who had been with company for nine years, and our Head of Customer Support, who also been with company for nine years, and we did a strategic goal setting session after the first quarter of this year where we brought a bunch of people together in Pittsburgh. And these are two women who work with each other day in and day out, sometimes on the phone or answering emails, many times a day, who had never met in person in nine years. And just that simple human to human connection, I think, adds a new dimension to any relationship. And so, we try not to forget that that’s a really important part of building a culture and an organization across all the different functional areas that we need to invest in and spend time on. Because existing and growing, especially in competitive environments, is hard enough, and trying to do that without having a good sense of who we are as a collective organization makes it even tougher. So, the good old fashioned get together in person, do social stuff in addition to hard work is all really, really important. And we try and be really thoughtful about how we get folks together and how often we do that. And quite frankly, we haven’t been doing it as much as we want to. It’s kind of a work in progress.

Alex Bridgeman: One thing you mentioned there was what sounds like trying to make work more public and available and transparent so the rest of your team knows the different projects that the rest of the company is working on and the progress within each of those, which of course, ties into remote work because not everyone can be in person together. What sorts of processes and maybe systems have you set up to make work more public and transparent at FSI?

Zach Seely: Yeah, so that sort of transparency aspect is something we’re thinking a lot about and trying to roll out. So, A, it’s publishing a lot more information than we had in the past. So, things like high level financial results and goals, slides or other output from board discussions, trying to bring that back into all hands discussions and talk about the context around it, why it’s important, how we did against how we thought we were going to do, those sorts of things. Establishing overall organization and team by team metrics is really important and tracking those in a very public way. In an organization that doesn’t normally do that, a lot of the initial reaction is you’re going to show me where my gaps are, where the team’s gaps are, and where we’re going to fail. And I think turning it on its head and saying like, I want to be everybody’s biggest cheerleader and celebrate all of our successes, but unless we know what our goals are, we don’t know whether we’re succeeding. And it’s really hard to throw an authentic celebration and authentically congratulate one another if we don’t set goals, sometimes really ambitious goals, and then hold ourselves accountable to meet those. So those elements are really important. I think that the technology that you use and the channels that you use. We were, and still continue to be in many cases, overly reliant on email, which is not a collaborative channel for discussion. It is a statement that can be interpreted in a lot of different ways. So, if you aren’t getting on a Zoom call with your camera on and talking – obviously, if you’re going to meet in person, that’s even better – but if you’re not getting on a video call, having a chat function where it’s much more of a dynamic conversation, a call and response, we’re trying to promote those channels much more than sending an email that’s complicated and has a lot of different types of information and it’s hard for various people, especially if you’re copying five or six people, to weigh in and get the input that you need in order to keep moving forward. So, it’s a number of different things. And from the CEO standpoint, you kind of got to balance what am I kind of dictating that we do and what kind of practices do we build authentically as an organization that resonate with people that people are going to use and find the value in, and there’s always a give and take. Sometimes, you need an executive leadership to just say, hey, here’s how this is going to work moving forward. And sometimes, you want a much more authentic buy in to some of these channels or tools or goals and metrics and that sort of thing.

Alex Bridgeman: And one thing we haven’t discussed or we haven’t touched on too deeply that we’ve mentioned here and there is outsourcing versus having your development team in house. Kevin, I imagine there’s different sets of tasks that are suitable for each side of the outsourcing versus insourcing. How do you kind of think through which tasks or which positions work best, outsource versus insource? And is there one direction that you feel CEOs should try to lean towards?

Kevin Knoepp: A lot of it depends on what the company has done historically. I have done a couple of diligence deals where the company had a fully remote development team, in India or Pakistan, and their developers are fully remote. And that does bring some interesting challenges in tech diligence because we want to understand are they a viable going concern? Are you their only customer? Are you getting the same people over years? Or are they switching people around on you a lot? And kind of what are the economics of it? What are you paying? And also, if you use a firm, an outsource firm to do the vast majority of your software engineering, how much are you actually- how much more are you additionally spending to get them good specs and get them good design documents and to sort of manage them? I do think, when we talk about outsourcing, there’s kind of two different approaches. And one is staff augmentation, which I think is a phenomenal way to bring more developers into an organization, where you hire someone, and for all intents and purposes, now that we’re all remote, or most companies are remote, they’re just another developer. They just happen to be overseas. And we’ve been having great luck with it, especially down in South America. Colombia, Argentina, Brazil are doing some, just have some amazing technical colleges, and there’s some great people out there. The problem that we’re seeing a little bit is that, globally, developer salaries are equalizing more than you would think. So, really good, really senior developers, you could be in Mexico City, you could be in Argentina, Colombia. People are figuring out what they can make now, and I’m seeing prices for certain classes of developers equalize with what you would pay here. There’s still a pretty great discount on what you would pay here. As far as like piece work, I just want to have the front-end or I just want this sort of back-end development thing offshored, there are a lot of considerations you have to take in because you might save money on the software engineer labor costs, but you also need to spend a lot more time on management, on design, on giving really, really good direction. The companies I’ve seen that are really successful with it are big enough that they have people that are dedicated to this, often people that are from the culture or even on the ground in the countries that they’re working with. So, it is not anything to be taken lightly if you want to just outsource. And if you do buy a company where the entire software team is overseas, you just have to think about your comfort level with that. And what I would usually recommend is, on any significant size deal, get a couple technical people at least so you’re not a lone founder who has to take all of their information from a representative of this external company. You have your own people that understand software, can read the code, can make sure that tests are being done to make sure you can audit things. It’s still a great way to do it. Personally, I’m always more comfortable, over my career have been more comfortable with having my own developers. And again, they might be remote developers in a staff augmentation model. But it’s just like your comfort level for dealing with having an intermediary between you and the sort of code base.

Alex Bridgeman: Is it common for software companies to offer some outsource services or some sort of budget for outsourced services to developers just to make their life and processes a little bit easier? Like, there’s a company I know that gives all of their technical folks like $250 to $500 a month to Upwork. Like they just get this budget that they get to use however they want. Have you seen examples like that where the insource team is using some sort of outsource service to take care of maybe some more like menial tasks that allow them to focus on kind of higher-level work?

Kevin Knoepp: Not in that model; that’s actually really interesting. I do see things where there will be chunks, like if you look at a QA operation, a big part of what modern QA does is pure regression testing. You take a test matrix which outlines all of the things like the happy path through the program that we want somebody to sit down at a computer and click away on. Outsourcing something like that to a much lower cost set of QA engineers, and there’s some great organizations. And again, this is great for the Philippines and India and Pakistan have some great deals where it’s just like here’s the test case, it’s rather binary, either worked or it didn’t. And if it didn’t work, you’re documenting what didn’t work. I’ve not seen situations where an engineering manager says, we’re just going to kick this work out. That’s really interesting. But I haven’t actually come across that. I do see some things, there are systems like Mechanical Turk and Take Five where you can like send particularly menial jobs out and get them back. And I imagine if you’re an AI or ML company, where you’re just training models, maybe you’re doing that sort of thing quite a bit. I’ve seen companies like you could go get like one particular job position on Upwork, like let’s say, you’re moving to a new technology platform. You have nobody in your organization that knows Kubernetes, you need somebody to set it up for you, go grab somebody off Upwork for a couple of months engagement. That’s kind of the same as finding any good contracting firm that can drop a person in that’s a subject matter expert.

Alex Bridgeman: Building on teams just a little bit further, now that you have maybe a good grasp of the characteristics of your technical team, how do you evaluate if work is accomplished at the level that it should be? Like how do you kind of measure capacity for your team and evaluate whether they’re utilizing capacity properly, or if there’s some underperformance and areas of improvement?

Kevin Knoepp: Yeah, that depends a lot on the size and kind of the talent level of the engineering organization. Done right, Agile and Scrum, there’s a lot of metrics you can look at around velocity and burn down and hitting their estimates – is the team hitting their estimates, and what’s the customer value looking like? Are the customers happy with the product? Are you delivering something that is high quality and is kind of nailing the features the customers are interested in? Quite often, in smaller deals, you could have a two, three, four, five person team, and a lot of those big sort of measurements and metrics really are not all that useful. So, I never looked down on what we call management by walking around. If you have a really small team, and you’ve got a technical manager that is able to read code and understand bugs and blockers and design and architecture, he or she should be able to, through participating in design reviews, participating in code reviews, participating in demo day, if you’re doing sprints, whoever your engineering manager is, should be able to have a pretty good sense of who’s pulling their weight and who’s not. And I see that fairly commonly in the deals I look at up to like eight and ten developers is that like, they just talk a lot. And sometimes I’m always like surprised. It’s like, what do you mean you don’t do sprints? What do you mean you don’t do any of the Agile ceremonies? And it’s just they are on Slack or on Teams or whatever all the time, they talk, they have enough organization that they’re writing what they need to be writing. Quite often, there is like one or two personalities in that sort of environment that sort of just mastered the product, understands the customers, understands the space, and can say you do this and you do that, and it’s very successful. So, I think it has a lot to do with sort of the scale of the organization. And when you’re talking to the sellers, if you’re buying a team, it’s pretty easy to say, well, our team is great, but yeah, we don’t hit our delivery dates and we’ve missed this thing, and we’ve missed this milestone, we’ve missed that milestone. And it’s like, well, then from that standpoint, your team is not all that great. They have some work to do to be able to meet their commitments and deliver quality software. Again, it kind of depends. But you can have a small team without a whole lot of process that is quite effective. And you can have a big team with great process that isn’t. So, it’s just sort of not one size fits all.

Alex Bridgeman: I want to finish our conversation with a little bit about pricing. I personally find pricing just an interesting topic in any industry, but especially in software. I would love to hear, Zach, from you, how did you evaluate, emphasize pricing strategy? And what changes have you been considering making or are in the process of making to pricing?

Zach Seely: Yeah, I think one thing that was really interesting when we were evaluating the acquisition was I think pricing really- very early pricing decisions really drove a lot of bigger picture strategic product development decisions in the sense, in the past, I had released our core product and priced it a certain way and then felt sort of hamstrung that because that product was priced this way, anything else that we did, we would need to price it less than and in a similar kind of structure. And the only way to kind of grow in revenue would be create more modules, as opposed to just making the core product bigger and whatnot. And I’m not saying that that was necessarily totally the wrong way to develop the product. But it certainly was interesting that how we priced CMS, our core product, early on actually, I think, was a big driver of the ultimate decisions that were made. So, we knew we wanted to take a different look at it. We ended up moving to a very different pricing model that we actually think is much more advantageous for both FSI and our customers to get the best of our overall product suite and capabilities. We’ve moved much more to an outcome based bundled go to market strategy and changed some of the pricing value metrics from sort of facility or departmentally oriented to per users. And that’s got a lot of- there’s a lot of important drivers there. But I’d say, too, your product development and your pricing are not distinct. There’s a lot of overlap, and they need to be considered together. But I don’t know that I would necessarily start with price first or certain price constraints and then build your product roadmap based on that. We’ve certainly kind of taken a step back and re-thought about both areas and made different decisions then were made in the past. And it’s been an interesting component of the dynamic. And quite frankly, we’re seeing now accelerated commercial success, which is translated into accelerated financial success based on, I think, some of the big changes that we’ve made on the pricing and go to market strategy side.

Alex Bridgeman: That’s fantastic. That’s cool to hear. When you look at different software companies and are advising searchers, what common parts of a pricing strategy are often deficient or missing or could use the most improvement?

Kevin Knoepp: So, I don’t spend a whole lot of time during the diligence on sort of like the market fit and figuring out what the market will bear. What I have seen in companies after they’ve closed, a fairly common pattern is to raise prices – we were charging this and now we’re going to charge that. And I’ve actually rarely seen that backfire. I’ve seen a lot of companies historically that were just selling their software for too little money. And companies, I know one company tripled their prices, they didn’t lose a single customer. So, they were obviously leaving a lot of money on the table. It depends on sort of like how SaaS-y you are. If you’re a SaaS company and you have a fairly consistent product across your entire offering and you can offer good, better, best, that’s always great to do. We do see a lot of companies that are trying to make the transition into SaaS software, and some of the businesses that we just walk away from, the seller comes to us that we’re SaaS and we want a SaaS multiple, and here’s how we can price it. And you’re looking at it, it’s like you’re not a SaaS business, you’re a custom software development shop. Every one of your customers is a snowflake, and thinking about consistent pricing when no two customers have the same set of features doesn’t make a whole lot of sense. And some of the deals that we’ve walked away from is when the seller wouldn’t let go of this idea that they deserved a SaaS multiple for the product. Yeah, I think that probably the one thing that, when you’re buying a company, it’s like don’t be afraid to go deep on what if we just doubled the price? What if we just tripled the price? Would we lose that? And if you’re competing on price, purely on price, it’s never a great position to be in to begin with. But again, that’s not a side of the businesses that I go that deep on.

Alex Bridgeman: Yeah, that all makes sense. Moving into closing questions. What strongly held belief have you changed your mind on? Kevin, maybe we will start with you.

Kevin Knoepp: Just on anything?

Alex Bridgeman: Anything, yeah, any belief, anywhere. Ideally business oriented in some way or with some connection, but we’ve had a lot of personal answers too.

Kevin Knoepp: I was born in California, and grew up always assuming that the United States was, in its own imperfect way, was synonymous with democracy and the rule of law. In the last five years, I’ve started to wonder if we always will be a democracy and if our laws are gonna apply to everyone and you know, that’s kind of depressing. I know this is a business podcast, but you know, if you can’t vote the political class out and these leaders can invest in stocks, they can own companies that they’re legislating over, they can skip paying taxes with no oversight; I mean, how do you run a company that competes with that?

Zach Seely: Yeah, I was going to say, or I’ll say one about sort of my role as CEO, but the world around us, there’s so many macro elements economically and otherwise that you just were so assured of, and so operating a business in these changing and volatile times is certainly challenging. On the CEO side, in terms of my role, one of my biggest learnings has been, walking into this business, I thought my chief responsibility was around vision and strategy, and then obviously, execution, that’s where my day to day focus was going to be, on vision and strategy and making sure that we nailed that. And I’d say, I totally feel that while vision and strategy is critical for a successful company, my role is really on hiring the best people possible and really focus on culture and the organization that we’re building. So, it’s much more on that organizational dynamics side and making sure that we have the right people to tackle evolving industries and macroeconomic challenges and customer needs and all of those types of things.

Alex Bridgeman: What’s the best business you’ve ever seen?

Zach Seely: I don’t know about absolute best, but I will say, I serve on the board of a company called JM Huber Corporation. It’s a six generation business. And Huber is guided by four what they call Huber principles, which are pretty high level basically values for the business. And the amount of time, effort, resources that go into instilling and reinforcing those principles, it’s astounding. But the impact that it drives, the alignment across the organization, it’s a diversified multinational industrial manufacturing and specialty chemical business with product lines in complete polar opposites of each other. But the alignment around the four Huber principles is so powerful, it’s just been a phenomenal lesson in terms of both leadership, but also- in people leadership and organizational leadership to really focus on the things that the organization believes in and devote the time, effort, resources to reinforcing those, and it’ll enable you to accomplish just incredible things.

Kevin Knoepp: I have a probably a pretty cliche and boring answer, but I’ve always been a pretty big Apple fanboy, and especially the hardware side of the business. The bulk of my professional career, I’ve been using various Apple devices, and I’ve just been blown away, certainly all through the Steve Jobs focused era of like their ability to innovate and so many things that they changed. I feel like they’re still going pretty strong. And I think that’s a pretty incredible business, although, like I said, kind of cliche to throw them out there, I think.

Alex Bridgeman: Not cliche at all. There’s been a few Apples and I know Chick-fil-A has been brought up three or four times. That’s always a good one too; people love that one. Well, thank you both for coming on the podcast. It’s been really good to chat more about software and due diligence. It’s a topic that we’ve explored less so on the podcast, and so it’s been great to have a deep dive with you both today on it. But yeah, thank you for sharing. It’s been fun.

Kevin Knoepp: Thank you. This has been great.

Zach Seely: Thank you guys.