VP @ REPAY | The AI in Payments Playbook: Accuracy, Human Review, and Guardrails

Kish Khemani 00:00

It was my first job in 1993 and it was to work on a C++ compiler. Every code check-in requires at least two peer reviews to get a different set of eyes on the code and then to have people on the team learn from each other.

Josh Anderson 00:16

Did you ever sleep during all this?

Kish Khemani 00:18

Not really. Team members are using AI to the do the reviews. It's good for doing the basic review. the team members are not really learning anything from it because the issues that get found are the same issues that get found by everybody because it's what the AI knows and that's it. It doesn't catch the unexpected issues that would come up just from being an experienced engineer. Everything now has a human in the loop. So no decisions are made just by AI agents.

Josh Anderson 00:45

Is AI changing the way you lead or is it just changing the way your teams work? Welcome to Tech Teams Today, where we talk with the people building and leading the engineering orgs behind today's most innovative companies. Our guest is Kish Khemani, VP of architecture and business payments at REPAY. You're going to learn what it is like to lead a global engineering organization. Kish shares his secrets to managing multicultural teams while also delivering an equally diverse product portfolio. As a veteran of over 40 acquisitions, few people are as well-versed in the challenges of leading across the globe. On to the episode.

Welcome to the podcast, Kish. Very excited to have you. As you know, our podcast is Tech teams today. So, what we need to learn first and foremost is what your tech team looks like today. So, share with our listeners and viewers the shape of your team, how big, just the general details about your your work.

Kish Khemani 01:47

Okay. Yeah. So currently it's a pretty large team. so the approximate size is about 20 people. and we've gone back and forth on splitting it up into couple of teams cuz I'm sure you know you know there's that recommendation that oh a team should be the size that a pizza pie you know a big pizza can support. So, you know, not more than eight people maybe, but at least I've had small teams and big teams.

And currently we did look at breaking it up, but the way our application [snorts] is written, there's a lot of dependencies and a lot of different modules that you know, so we need a large team to be able to interact on a regular basis because none of our modules are independent. and they're all dependent on each other. So that's why the team is pretty large which brings its own challenges.

But in general out of the 20 people that we have on the team that I have there about this 12 no 14 there's 14 engineering resources we have or I would say five as tech leads and then there are but seven or eight actually developers who do a mix of front end and backend development. there's a couple of QA engineers. There's a DevOps engineer. We have a development manager. we have a scrum master/ project manager and then we have two product owners. and so it's a pretty large team and we meet every day.

So we have a daily standup and even though you know a standup or the goal was to have not more than 15 minutes in a standup it usually ends up being 30 to 45 minutes but I feel that communication because we are a larger distributed team it is important to you know make sure everybody's in the standup and is going back and forth on different issues. So that's kind of the composition of the team and we are also a distributed team. So we have people in the US, in South America, in India.

so it's a large and in different time zones obviously even in the US we have people on the Pacific coast on central on the east coast and then South America a lot of those times are similar. So a lot of people are in the central time zone but then there's the challenge of also working with people in Asia which is you know right now 10 and a half hours you know time difference.

Josh Anderson 04:50

Yeah, I I've I've been in that spot where your team's borderline are a little bit lar larger than what their recommendation is. And I've been in a spot like you where I'm I'm going to buck the trend. And it was something that I actually had a discussion with the team about about, hey, technically speaking, we should break this up into smaller teams. What do you guys think? And they had probably a similar discussion what you and your team have like, yeah, we could do that, but like what do we gain? What do we lose? And all those things.

So yeah, I I I think it's really good and interesting that you and your team is like, you know what, we're going to stick together. We think it's best for communication, right? And to optimize all of that because that that's what can make or break a team. So I think it's really good and inspiring for you to focus on that first and then let all the other stuff kind of figure itself out.

Kish Khemani 05:39

Yeah. Yeah. And and I think we did try like at my previous company where we had actually that time we were 18 people and so we did split it up into three teams of six cuz that was the recommendation. And what we found was there was like a lot of times there was a lot of duplication of effort if you will cuz some of the same people like the engineers was okay okay they because they usually worked on different areas of the application but everybody around it.

So whether it was the team leads, whether it was the QA people or even the project managers or the product owners had to attend all three of those standup meetings all the time, whether it was a planning meeting or a stand-up meeting and so there was a lot of time spent just in you know wasted time I would say in there and so we we went from we had three teams initially and Then we went to one team and then that in that scenario even though we were just 18 people we sort because people were used to working in smaller teams there were challenges where people are like oh I'm I'm wasting time in this meeting so then we there we made the compromise and ended up splitting it back into two teams of nine each so you know it like you said I think a lot of it depends upon the team dynamics what works for you, the application that you're working on.

so there isn't really like one sizefits-all, at least I found in my experience. So teams of six have worked great, teams of nine have worked great, team of 20 has worked great as opposed to and the same size teams also were cases where none of those teams sizes have worked well. It just depends upon the team and the folks who are on the team.

Josh Anderson 07:42

Yeah, I think that's a really great message for folks to hear is that there is no single answer. There is no perfect team size that applies in every product, every portfolio of products, every company, every distribution of humans across the world, all those things, right? So there there's so many variables that of course you can walk in and say, well, this is how we should do it. But then once the practicalities start and you start aligning what's best for us, then I think that flexibility where you and your teams have tried things really lands you in the best answer for you and your team.

So I think that's really great for folks to hear, right?

Kish Khemani 08:20

And be willing to just on that be willing to adapt because that's what we said. We started with one size and then you know you try it out and I found at least in my experience it takes about 3 months for to get sort of the you know the workings of the team together to understand and the communications going and so in 3 months or 6 months if things if you find it's not the right size or the right team dynamics then then change it but yeah it adaptability I think is really key and important important in there.

Josh Anderson 08:57

Yeah, agreed. And everything in our world historically has changed so fast and it's changing even faster. So that adaptability is more important than I think it ever has been. Okay. So you mentioned a global team. How did you become global? Was it through acquisitions? Was it you just started at hiring everywhere? How did that shake

Kish Khemani 09:18

Out? So a combination at different companies. it's been through different means. initially it was not through acquisitions. So in my current company it's been through acquisitions but in one of my past companies it was more the trend started during offshoring. So about 15 20 years ago you know back in the late 2000s I think I first got involved in that in 2008.

where it for you know various reasons financial and otherwise you know we were told okay you need to start looking at offshore development and so I think that's where then the the distribution started where initially it was you got a project and you know you sort The first thing that we tried was offshoring the whole project to a team you know in a different country and that team was more of a self-sufficient team and only the manager was in the US and so that worked in some cases but in a lot of cases it didn't because then again it was the same thing whether it's an offshore team or an onshore team there was a lot of duplication there was a lot of handoff and there was not enough communication between the US team and the offshore team.

so then we decided okay well let's kind of merge the offshoring and the onshoring teams together and and then have a common sort of lead or a manager either on the US side or you know the offshore side and we worked with I worked with teams in when I say offshore it's in different countries too initially it started with teams in India And you know but then over time you know I've worked with and we got as more and more offshoring countries got involved you know worked with teams in Vietnam in the in Eastern Europe the Philippines in Australia and then South America came into the picture.

So the teams in South America and so that the initial distribution of resources started with offshoring and then in some of my my last two companies actually we went through a lot of acquisitions and so then it was okay when we acquire usually a smaller company and that company had its own teams in in one of the cases It was where the company was based out of Ireland in the you know so that whole team so that was not really an offshoring they were all employees of the company but that team was based out of Ireland and you know we didn't expect them to move to the US and neither you know folks here were going to go there so that's how that team got distributed was through an acquisition but then also through other acquisitions where a lot of the teams that we companies that we acquired had teams that themselves had distributed offshore resources and so that's how we got sort of resources in different countries even where oh we acquired this company and they had an offshoring team in Philippines you know and we had an offshoring team in India well once we became you know one team you know then we had now those resources were used to working or were part of the product and the team and the company for you know years.

So we didn't want to just try and consolidate. there have been cases where we've tried saying oh we have too many offshore vendors and you know let's try and consolidate and what I found is we had in one case at a previous company where we were told by our exec that okay we have to get rid of all offshore vendors and consolidate only on one and that didn't really work out the best and so what we've tried to do whenever I have had a request about consolidation.

It's like, okay, yeah, we don't want eight different vendors, you know, from eight different countries, but at least if there are two or three, then that's fine. You don't have to all consolidate against one offshore vendor. so and that's to me has worked pretty well. So even in my current scenario we have three different vendors who you know we acquired over the years from different company and u they are distributed in like some are in South America some are in India but that's worked well so that how we've my teams have been structured offshore and onshore is primarily either through offshoring or through acquisitions.

Josh Anderson 14:37

Yeah. So the thing that I heard is very similar to how you and your team figured out to work. The recommendation that your executive was working from is you should consolidate to one vendor makes total sense on a spreadsheet. But to actually execute that gets a little bit harder. And so what what you found is again find what works for you. And for you and your companies or products, it's been okay. Yeah, we should reduce from eight or whatever the number is, but getting to something that's more manageable.

but the air quote ideal state really isn't ideal and to have that adaptability to try it and then and then dial it back in. I think it shows great leadership for both you and your your team. So one of the things that I want to hear from from you is number one did you ever sleep during all this? If you had teams covering the entire globe, were you ever allowed to sleep? Not really.

But so over time you learn to you know as you get more experienced and as you have multiple teams you learn to identify sort of leads or people that you can depend upon that are in a particular time zone so that you are called or you have to get on a call or check your email only in cases of emergencies.

and so the way we've worked is you said because there are teams that I've managed in different you know time zones in different countries usually what I've gone through and what has worked well is okay identify what we call a daytime crew and a nighttime crew and you know and then identify leads on each of those and so the leads then sort of manage those the nighttime crew, you know, is managed by a nighttime lead. The daytime crew is managed by a daytime lead.

And the you only get called or you only get called in the middle of the night or if there is an actual emergency or if something that's critical or you know and the more common scenario has been where it's an offshore team because most of the companies the IT folks the you know the infrastructure folk are all usually US- based and so the more common scenar where I've been called is oh there access to or a system is down I mean now we have you know cloud systems everything is in in the cloud so you know those are up and running 24 by7 but especially if there is a a work that needs to be done or a reboot or there is an issue with networking that the US-based IT needs to work on and you know when the offshoring team is comes in you know which is their day and our night and they are hard down.

out you know you have a team of eight people who's sitting over there and they can't even log into the system or one of the core systems is down you know and then it's like you don't want them to waste their entire day till somebody in the US comes on you know online so that's when okay then see if you we have a process in place to usually do an on call person and but on call person is not responding so then it's like Okay. Call cash, you know who can then, you know, call somebody else to get see what's going on. Yeah. Yeah.

So, [sighs] how have you figured out effective management of those cultures because all of those cultures are different in all really good ways. But that's a lesson that I had to learn was that it was more than the accents or the time zones. it was understanding a way of life or a way of looking at work. What's your journey been in figuring out how to work with all those cultures across the globe?

Kish Khemani 18:53

So, there's been two sort of cultural differences or learning paths that I've had to take. one, it's been a little easier for me in particular because you know I've grew up in in the Indian culture.

So I understand you know a lot of the Asian cultures and you know what they are taught when they are you know in school you know and how do they interact with colleagues you know even in even though I've never worked there I've always worked here but still having that background has helped a lot but the bigger difference that I have found in terms of cultures is the culture of an employee as as opposed to a contractor. And what I have found is for contractors there isn't that sense of ownership of the application or the code.

but also there is a cultural difference where they they don't really say no. they don't say no to and I've tried to explain that in the terms of a a project like you give a a team a particular feature and a deadline and say okay we need to this have this delivered in a month okay end of you know end of [snorts] September for example and what I found was often times with folks in other cultures they Because the assumption is you are the boss and you never say no to the boss.

So even though going up front there might be that that oh this is not possible. I cannot do this you know this work by the end of September and it's going to take to at least the end of October but they won't say no or they won't raise a concern till the week before it's due. Now you're in the third week of September and they're like, "Oh, this is delayed." And so that has been u a thing that I try to do and I encourage others to do is upfront like you know you're not going to get fired if you say no.

If you have a concern, raise it and raise it sooner rather than later and give reasons why you think this is no. You know, don't just say no because you know cuz that's the other or it's going to be too much work.

No, if you feel that something is deliver is there's an issue with the delivery especially in terms of deadlines then or even in terms of implementation or design you know often times I'll hear well yeah we were running into issues you know performance issues for example and it's only when we started doing those performance tests at the end of the release cycle and now we're running into issues and I was like why didn't you say anything when we actually doing the design.

Well, that's not, you know, you're the architect or you're the boss, you know, and so it's and a lot of the non US cultures have that, you know, that fear or the lack of confidence or just the way they've been brought up where they don't speak necessarily their mind, you know.

So that and that has taken one to bring that up front in the as soon as when a team is formed to say you know hey there is an open line of communication here you know it doesn't if you are not comfortable bringing it up with with me or your leader bring it up with your team lead or your you know or your project manager or your development manager just but bring it up with somebody whether it's a a concern about delivery whether it's a concern about design and you know and once they do it once twice you know and they feel like okay they're you know their words are being heard then I find that they tend to then speak up the next time and the next time.

Josh Anderson 23:14

Yeah I I I celebrate those moments like crazy just to highlight that yes this is what we want. Thank you for bringing this up. this is ex and and try and let people know that this is welcome because I think there's not I think but I know there's also pressure from for a contractor from their boss within their company of like we can't say no cuz we might lose the project we might lose the or we won't get another project.

Kish Khemani 23:42

Yeah. Exactly. So there's there's there's certainly a ton of pressures there and even with that pressure I've seen areas of the world that handle it differently. There are some that, like you you said, don't say anything until the very end. Then there's some that

Josh Anderson 23:57

Don't say anything, but they kind of mask it. So, they deliver a product, but it doesn't that's not ready.

Kish Khemani 24:03

Yeah. But it but it works. You know, it checks the boxes, but you don't want to

Josh Anderson 24:07

Put it in production. so yeah, so I I' I've had to learn those those lessons and understanding how each culture responds to that crunch and what their response is going to be. And one of my favorite lessons that I've tried to share with people is bad news never ages well. So like let's let's talk about it before it gets worse because bad news can get worse if you let it age.

Kish Khemani 24:34

Yeah. So why yeah there's some painful lessons learned. Just on the other thing I have found and in some cultures where there is more of a hesitancy if you will on written communication as opposed to verbal communication. And so if you get on a call with a team you know from another culture they are more likely at you know not in general but in some cultures it's they are more likely to express their concerns on a phone call than they are if you just you know they will not send an email describing you know or you know or send a document which describes it.

You know, if you get just if you get them on a call and ask them questions about, you know, what do you think about this or why do you think this way, then they are more likely to express those concerns, you know, in a verbal conversation as opposed to written conversation.

But there are other examples of where people are oh everything has to be documented and nothing you know it doesn't matter if you say it in a phone call it has to still be written down in some form you know of a of RCA document or a design document or an requirements document has to be flushed out and it has to be you know six pages. So that's also I I found a little bit of a cultural difference between verbal communication and written communication. All right. So I want to pivot into your

Josh Anderson 26:18

Role and you have a fair amount of diversity in your role just as it is. So as the leader of AI architecture and payments, how are you balancing where you spend your time or is it the AI architecture feeds into payments? What does that time split look like for for you? How do you manage that?

Kish Khemani 26:39

Yeah. So, you know, going more to so initially it started with an architecture feeding into payments. But the last few years as AI has gotten more and more common now or you know the use cases and the use of AI and it's gotten more powerful.

So I've been lucky enough to be in AI right from you know the last four years and when it comes to AI in particular I feel like the a lot of the teams I what I encourage people is don't use AI for the sake of using AI when you are looking to implement AI in a project don't just bring in look to see first what problem are you trying to solve. solve and then ask the question is AI can AI help me solve that problem and if it is then use that to feed it into your actual application or your everyday work.

So in in my role that's what I've tried to do is ultimately payments is the the vertical or the business side of things and everything is driven off our business requirements.

So to me whether it's AI, whether it's architecture, everything has to drive ultimately to our business objectives you know so especially from having worked in technology and worked in different industries and different products and architectures over the years what I have found is it you don't let technology whether it's you know AI or architecture or design or even a coding language determine what they shouldn't be the driver you know now I love technology right and so early on in my life I was like oh this is a cool new language or this is a cool new tool or this is a cool new product or you know our competitor is doing it this way so we should do it this way too that almost never works because it's really driven by your your business objectives your revenue objectives and let start with those and let everything else feed into it.

And that's usually when you're successful as a team, a product, a company. So I've tried to follow that same pattern through AI decisions, architecture decisions, all leading to the goal in in my current scenario being payments since that is our primary business objective.

Josh Anderson 29:24

Yeah. How have you managed the riskreward of AI in a space like payments? Nobody likes when their money gets messed up. So you can't live in a world where you're like, "Oh yeah, it's a thing. We tried it. We shipped it. It didn't work." That's not going to be acceptable in the

Kish Khemani 29:40

Payment space. How do you manage that? So very carefully. the cuz one of the things that people tend to forget about AI it's it's hard to be deterministic when it comes to AI tools you know models right I mean it's great for like the whole AI thing took off and generative AI came about right and oh creative being creative and there are you know obviously different now the AI tools and models have gotten so good that you can sort of measure or you can set parameters for temperature and you know just different parameters to get accuracy over you know creativity.

But still because of the especially when it comes to our industry and payments in particular or finance, anything in finance where like you said even a small you know an error in a basic logic error could cost you millions of dollars. So one the tools we use the AI that we use is all driven towards as much accuracy as you can. and but then when it comes to also everything now has a human in the loop. So no decisions are made just by AI agent. So you know in the last year 2 years everything is about agentic AI.

So we have you know agents AI which is doing things for us but as it's doing things no decisions are really made without a human in the loop without somebody who's actually looking at the actions that have been taken by the AI and at least giving a checkbox of approval before it actually goes you know and takes that action also approves it.

So that's kind of the two things where especially in our industry where we've tried to encourage people to use AI but use it the right way by keeping more of a focus on accuracy and then two by putting checks and balances in place to you know and one of the common things that has actually worked recently is any agents that we build or any AI tools that we build to always have a feedback loop because the thing with AI is the more feedback you give it the better it tends to get.

So you know make sure that you are even the decisions that a human makes or decisions that so we actually use in some of our projects we use multiple AI models or tools and we have them review each each other's code. So you know one AI is one model's output is then reviewed by another model not only just a model but of a different model family which then gets fed back into it. So one get the AI tools and the AI models to review each other then give it finally a human review and then provide that feedback again back to the AI models.

So that's how we kind of try to sort of limit the risks that AI brings, especially in the financial space.

Josh Anderson 33:18

All right. So last thing for us to talk about is we'll stay in the AI space, but you and I have both been in the game for a long time. we've been leading teams for a long time. Is AI changing the way you lead or is it just changing the way your teams work or some combination thereof? How do you see that?

Kish Khemani 33:40

It's both. and the the amount that it changes I would say it's almost it has as much of an impact in the way we lead tech teams the way I lead tech teams and the way my teams actually work.

So to the way I lead it helps me because I'm sure you know being just like you being a tech leader and usually managing multiple teams and multiple products you tend to spend a lot of your time in meetings and you know and when you do when you have multiple teams, multiple products, multiple meetings sometimes the noise you you tend to you know you miss some of the the nuances of it or you miss some of the things that you should be paying attention to.

So AI is great for that to you know do summaries to isolate or to do that review where you know if you had like at the end of every day you know all our meetings now I'm sure most people do at this point every meeting has AI notes you know not only just transcript but action items and notes so I do tend to at the end of the day or the be before the next day starts go through the notes the AI notes for all the meetings and to you know pull out primarily action items that you know and then prioritize things.

So I think the way it's really helped in leading is by prioritizing because you just otherwise you just don't have enough time.

[snorts] and then the way it's changed in the teams work is I've found like the teams themselves are they are definitely getting more productive because you know a good case is like in the on the tech side any application you write has unit tests right you you teach all the developers to make sure that you have enough test coverage well AI is great with that it's great at writing test coverage for it or going through code and finding known vulnerabilities you know u it's again it's great for that on the flip side the one concern that I have had is we enforce peer reviews of code so you know especially because we are a large team and we work on complex modules so every check-in code check-in requires ers at least two peer reviews and the intent of those reviews is one to get a different set of eyes on the code and then two to have other people on the team learn from each other learn from the leads learn other modules but what I found is a lot of the teams now member team members are using AI to the do the reviews and so while it's good for doing the basic review the team members not are not really learning anything from it because and the issues that get found get are the same issues that get found by everybody because they just it's what the AI is knows and that's it.

It doesn't catch the unexpected. It doesn't catch the edge cases. It doesn't catch some of the you know the issues that would come up just from being an experienced engineer. But so that's kind of the downside of people using AI.

But it's still you know so again just like the human in the loop for AI agents I'm trying to tell the teams the same exact thing which is just use AI as a tool but don't just rely on the output that it produces look at that output you know and because it's going to help you learn but then more importantly it's not there are going to be things that AI misses that you will catch you know so just don't just do a peer review and just depending upon copilot or cloud or any of the coding to the AI agents to

Josh Anderson 38:08

Just do the review for you. Yeah, I think that's where great leadership can really enable teams to work through the love affair or the fear of AI then the love affair of AI and then find that like again once you dial it in.

Kish Khemani 38:23

Yeah.

Josh Anderson 38:23

Yeah. It's it's it's a balance. I think that's a really great great word. Okay. So Kish, we have we we have done the hard work. We are on to the final question. So, these are the same questions every guest gets on the episode. you don't know what they are but they're not too scary. So, first one is there's a image format that is commonly used on the internet for animated images. It's pronounced a couple different ways. I know which way I pronounce it. How do you pronounce it?

Kish Khemani 38:54

Even GIF.

Josh Anderson 38:55

Okay. I'm a GIF guy. You're a GM, a soft. Okay.

Kish Khemani 39:00

I've had Yeah. Through the years, it's kind of to me it's like the Yeah. I don't know if there's a definitive answer. And you know, I worked in Silicon Valley for a long time and you know, we've had discussions. It's a it's a great dis debate if you will over beer or drinks you know and there are people who swear no it's GIF and there are people who swear it's GIF and I don't know I've I started saying GIF and so I've stuck with it and you can't convince me it's GIF just like I probably can't convince you it's GIF.

Josh Anderson 39:38

Nope. Yeah, it is one of those passionate debates that boy, if you get that going with the right crew, just like sit back and watch it go. Okay. let's talk about leadership and what's the most impactful piece of leadership content that stuck with you? It could be a book, a quote, a podcast, whatever it is, but the thing that you always lean on when things get tough.

Kish Khemani 40:11

I don't so I used to read a lot of books on leadership in the past. and then I don't it's sort of the almost the ADHD generation and I'm has I don't have the patience anymore to actually go through a whole book. So then I started looking at the or regularly going through the Harvard Business Review and their sort of leadership newsletters. and then even that has sort of died down if you will.

so now I find the most content that I the best content I get especially in terms of leadership is by just having conversations with other leaders and you know I do attend a lot of conferences I do attend a lot of meetings formal informal and so you know I find just conversing with other leaders in you know and it the industry doesn't matter. They don't have to be in technology.

It's just and in fact I find often times by not focusing on sort of the leadership traits or trends in technology but across the board you know tend to help me because then I can u it opens my eyes to things that I feel like I am so focused on technology all the time that by having getting a perspective from leaders in other areas sort of helps me guide you know my leadership beliefs and principles. So, I think conversations and meetings are probably the best source. Now,

Josh Anderson 42:04

I'm I'm I'm right there with you. I get a lot of questions about Have you actually read all those books? And like I've I've read all of them. I've not read every page of all of them. There's sometimes kind of like you I get halfway through I'm like, I don't care about this anymore. So, I certainly understand and appreciate that. Okay, let's talk about your personal operating system. not what operating system you're going to put on your servers. You're going to run in the cloud. But the one you prefer to work with, are you a Mac, Windows, or Linux guy? [snorts]

Kish Khemani 42:31

Yeah, I've worked through the years through all of them. And I'd say I started off with Unix because I got one of the first machines that I fell in love with was a Sun micro systemystem in Silicon Valley. And so you know it was that was it. I was a Unix guy. Then I was forced to work on Windows. and you know I became completely a Windows only guy. and then Linux came about and I became more of an Ubuntu Linux guy. but I would say over the last probably eight years now or 10 years. Yeah.

Since 2015 and I still remember 2015 I got my first Mac and you know I have I will never go back to anything else. So I my preference whether it's my home machine, my work machines I am a completely Mac guy now.

Josh Anderson 43:43

Yeah, I feel like that's a pretty standard for for folks of our generation. That's a pretty standard as an engineer. You know, you you started in Unix and then Windows became a thing and

Kish Khemani 43:54

Everybody wanted Windows apps. So we had to pivot to that and then eventually somehow you land in the Mac space like oh this is this is nice. So, all right. And especially doing AI, I was just going to say doing AI, I mean, the some of the the computing that you get or the performance that you get from a silicon chip on the Mac, I find I can't get it anywhere else. I can't get the same thing on a Windows box or even on, you

Josh Anderson 44:19

Know, a Linux box. Yep. Yep. Okay. So, last last one. speaking of growing up as an engineer, I need you to think back to the first professional product you ever shipped, whether it was you individually or you as a team, the first thing that you shipped. What was the technology that it was built on? [snorts] Do you remember?

Kish Khemani 44:43

So, yes, I do. I do cuz it was my first job in 1993.

and it was to work on a C++ compiler and the yeah I had I didn't I had a more of a background in C in school and you know so I just assume C you know and this is you know object-oriented programming had just started as a concept and C++ was relatively new and so I joined my that was my first job a startup in Silicon Valley and u it was to and I when I joined it was to work on C++ compiler and it was some of it was a small startup but I worked there with some of the smartest people I know a couple of people who actually were who knew who were on the C++ plus+ standards committee and you know people who are way way way way smarter than I was and I ever will be and it was quite an eye-opening experience and a very learning experience to the point where I actually had to take classes in the evenings just to get up to speed on you know because we were really we were building the compiler so this was real hardcore programming stuff And I didn't even think I wanted to do hardcore programming.

I wasn't really a you know a programmer and but I just fell in love with it and you know and then yes so I started with C++ it was a C++ compiler as my first product.

Josh Anderson 46:33

That is that is a great place to learn and I'm sure just as you mentioned some difficult lessons but I'm sure they've stuck with you

Kish Khemani 46:41

For a long time. For a long time.

Josh Anderson 46:43

Okay. last thing for those of our viewers and listeners that have watched all the way to the end and they want to hear more from you or learn from you, how do they get in touch? Is it LinkedIn? Do you have ex account? What do you prefer?

Kish Khemani 46:55

LinkedIn is usually my Yeah, I tend to not get as much on social media. I mean I do have everything from X to Instagram to everything else but that's usually for social media content and anything work or technology related it's I'm on LinkedIn and it's you know /Kish Khemani my u first and last name.

Josh Anderson 47:24

Cool. All right. Well, we'll make sure it's in the show notes. So Kish, thanks so much for being a guest and we'll see everybody next time. Sounds good. I really enjoyed our conversation. Thank you. Thank you. That was Kish Khemani, VP of AI architecture and business payments at REPAY. There has to be at least one person in your network that's going to learn from Kish. Go ahead and share with them. They'll appreciate it. I know I will. Tech teams today is brought to you by Revelo.

If you're looking to build out your engineering team with worldclass vetted talent from Latin America that's times on the line and ready to ship, check us out at revelo. com. I'm Josh Anderson. Thanks for being here and I'll see you next time. down.