Interview with Karan Zaveri, Chief Technology Officer at 24/7 Software

Transcript

Ledge: Karan, it’s really good to have you. Thanks for joining us.

Karan: Thank you for having me.

Ledge: Could you just give a little background story of yourself and your work, so the audience can learn about you a little bit?

Karan: Sure, absolutely. I’ve been a programmer ever since I’ve been 16 years old. I got this bug as a result of me being very naughty and having too much time on my hands, and my father decided that it would be a lot more productive if I learned something new.

So, he got me a computer and that’s where my journey began. Every since I had my hands on my first Mac, that’s where I was at that time, I wrote my first program and learned a bunch of technologies and languages, and got into programming really full time, so to speak, in a way that I used to go visit a doctor for a treatment that I was trying to have for my throat. Every time I would go there, it would be a long wait before he would have to go find my record. So one day I just, the impatient me decided to say to him, “Why don’t you use a computer to speed this process up a little bit?”

He kind of looked at me and he goes, “Well, you’re such a smartass, why don’t you go and build me something.” Three months later, I did come back with a version of a product that we then subsequently sold multiple times over. That was my journey into the entrepreneurial world.

Since then, I’ve started and closed many companies. We started ISS 24/7 back in the day, and now it’s 24/7 Software. In 2009, after another startup which I was a founder of failed, we are at this point the largest provider of venue management applications which are used by 400-plus facilities around the world.

The company in 2009, started out by simply providing a very simple text based messaging system for sports venues – especially for the Miami Dolphins. We grew that company and the team from two people up to a team of 64 engineers today, got acquired in 2017, and I’ve decided to continue to stay onboard to see where this goes. So that’s kind of a little bit of two minute breakdown of my journey so far.

Ledge: Well done, and you’ve covered a lot of ground in that time. Talk about that entrepreneurial bug and how it fits into being a tech leader. I know so many of our listeners will relate to that. That, wow, I want to be a technologist, and I like writing code, and I also like to start businesses. What about leadership?

It kind of becomes a time grab. You can’t do everything that you want to. So, how have you made that balance work?

Karan: Absolutely. One of the things I realized early on is, if you want to be an engineer you’re going to be an engineer. If you want to be an entrepreneur, you’re going to be an entrepreneur. If you want to be both, good luck. It’s really hard.

What you have to realize and understand, at what point when, if you’re an engineer, you don’t over-innovate a product. Where if you’re building something, you have to look at it from the business perspective whether it makes sense or not. As you start learning that, you’ll come to realize that there’s a balance that you need to maintain.

A lot of that has to do with experience. The more failures you would have from an entrepreneurial perspective will kind of help you learn and guide on what your engineering skills could complement with that.

So, I think there is no one-size-fits-all answer for this, but it usually depends on who you really want to be and what your career aspirations are.

Ledge: Talk about some of the learnings, some failures. I think we all in the entrepreneurial space certainly embrace the, if not fail fast, you at least have to fail a lot of times to learn things. What are some of the major learnings rising out of the failures for you?

Karan: One of the things I’ve always honed down on is one of the things that Mark Cuban has – every failure is one step closer to success. So, first of all you cannot let failure make you feel that you’ve completely failed in anything. It’s just another step for you to get closer to success.

Like you said, you do want to fail fast but every time I have failed I’ve sat down and looked back at whatever I learned from this and what I will do better in the future.

But when it comes to technology, and tech companies specifically, there are certain patterns that companies tend to follow. There are certain patterns which are common amongst successful companies. You have to really get to know what those patterns really are.

I know I’m talking in context of more of Silicon Valley companies and things which scale overnight and become a unicorn, and so on and so forth, but there are other companies which are relatively smaller, like in our case we are a very niche SaaS based provider. We’re certainly not a unicorn status company, but we are profitable. We are a successful business, and we do provide a great product to our customers.

The base core fundamental is, obviously you need to find a product market fit for the product that you are providing and customer service is one of the best things you could do. If your customers love you, you’ll be there for a while. We have had almost 2% churn rate year-over-year which, in a SaaS company, that’s one of the really low parameters to look at. You have to continue to innovate and provide value to your customers. If you fail to do that, you’re going to certainly fail as a company and as an individual also.

The list goes on and on. I can talk about this for a whole day.

Ledge: Absolutely. What’s that look like in an early stage company, where you don’t have unlimited resources for a customer success function, or account managers or all those things. You’re just trying to make it work. You’re trying to ship product. You’re trying to listen to customers.

What would you recommend on a customer focus, or a customer empathy focus, but for people that they don’t really have the capital and they’re really trying to bootstrap and spread it around?

Karan: Our example is a pretty good example for that, and I completely understand where the issue might be.

First of all, when you’re a startup, if you’re an entrepreneur, you’re kind of everybody. You’re doing accounting. You’re doing coding. You’re doing sales. You’re doing customer service. You’re doing everything. Be prepared. You have to be prepared for that.

That, in a way, is a blessing in disguise because every function that you touch within your own company and you work in that department, it will teach you something new about that. Later on when you’re ready to scale that, you will be able to use that learning and do the right things because you’ll know exactly what you did in those areas and how and what tone you want to set up.

As far as managing resources, it’s hard early on. Different teams and companies tackle it very differently. There are a lot of options these days. You can outsource a lot of things. You can get talent for relatively cheap from interns, if that’s something that your company could use as a business model.

Last but not least, if you’re managing 10 or less customers, you can certainly very well manage them yourself if you’re a small team of four of five individuals within a company. But as you start scaling, you have to build an organization that revolves around the culture of customer service. That has to be the central and core principle of your business model.

Ledge: Absolutely. That itself is, as you talked about, the pattern matching of experience built out of failures or half successes or what have you. How long did it take you to put that together? What number of examples and experiences create a pattern that you feel that you can rely on?

Karan: Well, in our experience, we didn’t realize that that’s what we should have been doing early on. I wish that would have happened early on for us, but it took us a while.

One of the things I would recommend is, start reaching out to all these successful CEOs and executives of other companies and speaking with them, networking with them, asking them questions. Also, at the same time, you want to communicate with all the executives of failed companies because they have a lot more to tell you than the ones that have actually succeeded. A lot of people, once they succeed, will forget a lot of their failures because they want not to remember those things.

So, I think having a balance and networking amongst that group certainly helps, and that helped us quite a lot.

Ledge: You talked about your own habit of a retrospective after any of the things that you did. Did you capture that knowledge, or was that more sort of a tacit back-of-mind thing? I’ve seen some founders come up with their playbook, and they actually write it down and refer back to it. Or was it more like a mental process?

Karan: It was more of a mental process. At this point, however, I do have something more solidified, written, documented. But this document, so to speak, kind of changes almost on a weekly or monthly basis because there are small failures, there are larger failures, there are bigger successes that we achieve one way or the other. It’s documented, but in my case a lot of it is also mental.

Ledge: How do you recognize the symptoms early on of maybe a bad pattern that you have seen before? Are there are a collection of, I don’t know, feelings or results or things that you can start to notice as you’re reading indicators?

Karan: It’s quite simple, actually, because if you have a mission statement about your company and if you have certain goals, if you’re not meeting those you definitely need to look at that in a more deeper way.

What I mean by that is, we became a very number-oriented organization in the last few years. We’re trying to target a certain number of customers and revenue. If we couldn’t get to that number, obviously we were not achieving those goals.

I think that’s one of the things that a lot of companies who are product and engineering driven will fail to recognize. That revenue is a critical part of growth that you need to maintain and be able to be profitable, and not just build or over-build a product.

That is where I’ve also seen a lot of companies fail. Where they would just go out and overdo the product and build something that the market doesn’t either really want, or is overbuilt for the market. So, those are the kind of patterns that you need to look for.

You can create your own indicators, but having some sort of benchmark that you can test your performance against, or your company’s and your team’s performance against, early on is really helpful.

Ledge: What are some of those key KPIs? Obviously, I think revenue has got to be on the list, and I also know that most folks would recommend you can’t have more than say five core things that you measure. What do those look like in your world?

Karan: In our world, biggest was the churn because we are in a very niche market space, and there’s only so many number of venues. We do have now a product horizon that spreads across different verticals, but that’s one of the KPIs. Churn was something we wanted to manage, and everything drove around it. It was more like, okay, what can we do to reduce our churn? Even though it was relatively low anyway, but that was one of the biggest parameters.

Second was customer success, because we knew that if we did a great job at servicing our customers it would automatically help reduce churn, and as a result would increase revenue.

Ledge: Customer success. What are you measuring there? It sounds to me like, retention certainly being the opposite of churn, how do you measure customer success?

Karan: There are multiple things that you could do. For example, if we are potentially soliciting a new customer and we give them a reference to an existing customer, how much they love us as a company and how much they’re willing to go out of their way to try to sell to our potential new customer is an indicator that we’re doing a good job as a product company and as a customer service company. That’s one of it.

We don’t maintain any kind of logs internally to see how well we are answering customer calls and so forth, because for us we answer phone calls seven days a week, 24/7. It doesn’t matter what time and when it is. The customer needs help, we’re there to support and help them. So, maintaining logs and any of that stuff doesn’t really help because that’s not part of our culture.

Just on that same topic, you can come up with your own KPIs, but I think having a customer happiness KPI is really helpful. One of the best things a CEO or an executive could do is reach out to customers randomly and talk to them. Ask them how we’re doing, and be open to feedback. Not everybody on your team would be the same as you would, and it becomes your job to coach them along, to bring them up to the company culture.

Ledge: Yeah. It makes me think this is what NPS is supposed to do, but it often feels like NPS is kind of a blunt instrument. I’m always ever wondering, how biased is the answer that’s coming back from this thing? The open ended feedback is very often not substantial.

Have you toyed with that at all?

Karan: Not really. Like I said, we are very different when it comes to that, so we haven’t really looked at that.

Ledge: Yeah. We got a mixed bag as well. It’s always an interesting thing. Love that number when it comes back high, but then you kind of wonder what’s baked into that from an assumptions standpoint. Nothing beats getting on the phone – or even better video – with the actual customers.

We’re in the business of hiring and retaining and making sure we have just the very best freelance engineers. I always like to ask tech leader guests, particularly who’ve been in the engineering seat, now in the CTO seat, what are your heuristics for hiring? You want to have the best engineers to your team. How do you figure that out on the way in?

Karan: Well, that’s a great question. First of all, we love to bring people into our team who love to create and build things. They certainly have to be intellectually on a higher level than anybody else, but also somebody who doesn’t like to give up, because those technical challenges are almost on a daily basis.

There are multiple different factors that go into recruitment for an engineer. I personally prefer to work with people who actually have passion for technology and a passion to change things in the world and space we are in. If you’re a sports fan, and if you love to build sports technology you’ll certainly be enjoying doing this.

But, hiring for us is a very broad topic. Again, it will take a long time for me to break it down.

Ledge: Absolutely. We hear that all the time, is that – I wonder if this resonates with you – how much of that is really based on qualitative things? It’s not just about code tests or checking code. That’s almost like the table stakes. That’s like the cost of entry. Of course you need those technical skills. I’ve asked this question a hundred times and the answer almost invariably comes back to; ability to communicate, soft skills, is it someone likable, problem solving skills, ability to demonstrate being a great team member.

When you think about items like that, the company culture plays so much into it because what’s a great communicator probably has some standard metrics behind it.

Karan: Absolutely.

Ledge: But in your company, the way you communicate is just different and the things that you value. Do you think about hiring from the standpoint of sort of core values, mission statement, kind of stuff?

Karan: Absolutely. Some of the aspects that you’ve mentioned, these are the basic parameters that we would go with. We have a team size of 65 within our engineering group, and we certainly have to have people who are able to communicate effectively with each other and are a great team player, because we have seven scrum development teams and they all have to work cohesively together, collectively together. All of them have to realize and understand what our mission statement really is.

We do also empower. Even if somebody is fresh out of college, there’s a lot of power and control that they have over how and what effect they could do as being a team member.

Ledge: It’s not just all about years of experience on a resume.

Karan: No. It doesn’t matter. One of the great examples I always give is, you could be working in one place for six years and doing average coding, or you could go somewhere and actually build up something really cool in one year. The experience of this one guy for one year is a lot more than somebody who’s doing a repetitive, monotonous thing for six years.

Ledge: Sure. So, how do you come down as a SaaS company now on remote work, distributed work? How do you deal with these issues? There’s a constrained labor market now and the best way to hire seems just to be just hire anywhere. But that introduces so much complexity if you’re not ready for it.

Karan: Well, we do have a global distributed engineering team. One of the ways we have solved that problem is…

Well, a couple of things. First of all, we have a very sophisticated development life cycle with separate DevOps teams, QA teams, and [00:18:59] engineering development teams. That’s just one piece of the component. I don’t think there’s a one-size-fits-all answer.

In addition to this, there’s also a process. The process really helps over here. You have to, as an organization, understand and realize what process works best for you. For some companies, a waterfall method of development might work. For some scrum is best. For us, scrum is best. Then for some kanban is best, and there are newer things being implemented in different environments.

I think having a proper, solid process for development, coupled with proper tooling and communication methods being set. Communication is obviously a key part of all this. If you’re going to have teams in India and Philippines and Brazil and the United States, you’ve got to be able to establish a proper method that all these teams are communicating within effectively. The biggest challenge that you’ll end up having is the cultural differences and expectations from every part of the world. So you also need team members who are open to the idea and are receptive to work in an environment like that. It all starts from there.

Putting the right process in place along with the right tools should certainly work.

Ledge: Absolutely. Well, Karan, thank you so much for the insights. It’s been really good to have you on.

Karan: Absolutely. Well, thank you for having me on.