Building Data-Driven Engineering Teams with Harish Vaidyanathan, Head of Product at Hatica

(Intro Narrator at 00:00:00) Today, we're talking to Harish, the Head of Product at Hatica, about the ways in which Hatica is boosting developer productivity and how Harish's dedication to running makes him a better leader. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:21) I was really interested to hear about you and your running. How did you get into running?

(Harish at 00:00:25) As they say, it's a midlife crisis thing. You're always looking for ways to get good at something else apart from work. And I think as technology people, we just spend so much time in front of the computer. It's just, you know, the easiest thing to do is just go out and run. And back in the day, I think this is almost ten, fifteen years ago, Nike had this really cool device. It was called the, I think, the Nike Running Pod. You could put it in the shoe and that thing would connect to your phone via Bluetooth. And then you would have all kinds of running metrics and so on. And, you know, tech people just need another data source to geek out on. So that's what got me into running, you know, just analysis, looking at data, looking at trends. And the next thing you know, I'm just hooked to this thing. And it's been, what, fifteen years now?

(Joel Beasley at 00:01:13) Wow. Yeah. How often do you run?

(Harish at 00:01:15) I try to get in four to six days a week.

(Joel Beasley at 00:01:18) How far are you running on average?

(Harish at 00:01:21) Weekly, I'm kind of now getting back to 50 miles, which is decent.

(Joel Beasley at 00:01:27) 50? Five zero?

(Harish at 00:01:28) Fifty. Five zero. Yes. 50 miles per week.

(Joel Beasley at 00:01:30) Per week?

(Harish at 00:01:31) Per week. That's what I'm trying to get to. But yeah. During training cycles, that's kind of where you go. Otherwise, you're just hovering around forty, forty-five.

(Joel Beasley at 00:01:39) Wow. I spent about three years running. And then I stopped when I got to the point where I was just consuming lots of food just so I could run. I was like, alright. I'm sitting down making time to eat just so I can run. I was like, if I just run less, I won't have to eat as much.

(Harish at 00:02:00) Yes. Yes. Runners tend to be fairly, you know, fuel powerhouses.

(Joel Beasley at 00:02:04) Alright. So let's talk about this. So you work in technology, and you use running as this outlet to keep away from the screens. I live out on a farm out in the middle of nowhere. So it's beautiful because I get to be on the screen all day. And then I immediately disconnect when I walk out of my office. And I'm in the woods. And then I have my family. And so this balance between screen time and outside time—super important. And people that are listening, there are definitely some people who have mastered it, but there are some people who know that they should be doing it and they want to get started, maybe baby steps. How do you suggest somebody get started with being more connected to outside and nature?

(Harish at 00:02:50) Yeah. I'm actually a fairly strong believer that you do your best work when you're not literally focused on that work twenty-four hours. So if you want to be really good at your craft and in technology we talk a lot about craft. If you really want to be good at craft, you can't be crafting all the time. You've got to take the time off to sharpen the saw, get diverse perspectives. And it's actually proven, right? Time and time again, it's been proven that going out for a walk or doing something alternative helps you develop different perspectives, with which you can potentially get better at craft. I call these, you know, serious hobbies, something that's all consuming, you know, whether it's painting, whether it's playing the guitar, playing a musical instrument, doing some physical activity, but essentially something that's all consuming, whatever floats your boat. You know, the moment you find yourself in the flow, in an all-consuming activity, nine times out of 10, you're going to come back energized and you're going to, you know, become better at your craft. That's my worldview, actually.

(Joel Beasley at 00:04:00) And it forces you to be there a 100%. Right? You can't be—

(Harish at 00:04:05) Exactly. Exactly. Yeah. Yeah.

(Joel Beasley at 00:04:07) Is this how a lot of people at Hatica think?

(Harish at 00:04:10) Yes. Yes. I wouldn't say it's our culture. But given the space that we operate in as a company, we really think about pushing the boundaries of what engineering needs to be, what the future of technology is and how engineers can get better. Right? So it's definitely something that we spend a lot of time thinking about.

(Joel Beasley at 00:04:29) And what have you learned so far? You're a—are you a startup company? You're solving a problem. Tell me about that.

(Harish at 00:04:36) Yeah. So, essentially, the space that we operate in is to help engineering teams get better. There's been a lot of talk about developer productivity. We think of this as engineering productivity, like the entire system has to be more productive. And a lot of things are changing, right? Obviously there was cloud and all of that a few years ago. Now it's AI, right? And some fundamental things have changed. Earlier, the entire organization was built around making engineering more efficient. So they would have product managers who would define the requirements, trim them down, do an MVP, do an MVP plus one because building stuff was hard. Writing code was hard. Turns out that's not the case right now. Right? You could ask, you know, GPT, you could ask GitHub Copilot to write code for you. So suddenly the agility with which you can ship is—has changed significantly. Right? And that's something we spend a lot of time thinking about. How do we make engineering teams more productive, more aligned with their business when the existing constraints are gone?

(Joel Beasley at 00:05:44) And how do you do that?

(Harish at 00:05:45) Yeah. So we basically connect with all the tools that engineering teams use, you know, GitHub, Jira, all these kinds of things and essentially pull out data which empower engineering teams. Now, if you take a step back, right, engineering teams provide data to a bunch of teams, business teams, product teams, everyone. But the engineering team themselves are not that data savvy. Like the most data-rich conversations they can have is how many Jira tickets did you close this past sprint? Right. Which doesn't tell you anything. Actually, it's just—it's a quantum of work done. And that's one part of it. The other part of it is you go into any engineering review and you ask, hey, what did you guys do? You would get a bunch of English. Right? You would get paragraphs and paragraphs of, you know, verbose comments on we solved that problem. It was a hard problem to solve. We unblocked the customer. We launched this feature and all that is great. But the question is we really need to look at everything engineering is doing in terms of, hey, are you working on things that's important for the business, right? Are you heading in the right direction as engineering? Are you doing things fast? Are you following engineering best practices? How are the people doing? Right? You don't want to have, you know, engineers working forty hours a week or eighty hours a week because that's not sustainable. So you've got to think about people well-being. So these are some of the data points that we basically sum up and present to engineering teams, as well as, you know, the finance organizations, the management, and so on. We like to think of this as data-driven engineering, actually.

(Joel Beasley at 00:07:26) And so what type of problem if I'm a tech leader—I mean, a lot of people listening to the show manage technology teams. Right? What problem am I facing? What pain am I experiencing that I think, okay, this sucks. I need to go use Hatica. Like, why would they come to you? Why would they find you and then say, okay, we're having this business problem over here. Here's the pain. Your product solves the problem. What is that?

(Harish at 00:07:51) Actually the stuff that our customers come to us for are three things actually. Number one is what percentage of work that engineering is doing is actually aligned towards the business. That's the number one thing, because it turns out engineering does a lot of work on resolving technical debt, you know, keeping the lights on, fixing bugs, and anything that's new work tends to happen after all these other things are taken care of. So that's the first thing, you know, business alignment—is engineering pointed in the same direction as the business. That's the first thing. The second thing is if engineering and business are pointing in the same direction, how quickly is engineering moving? You know, what's the velocity with which you're going? So direction, velocity. And the third thing, of course, is the quality of how engineering is delivering. Are you planning and delivering things correctly? Are you delivering the things that you said you will deliver? Or are you delivering something else? So those are sort of the three things, direction, velocity, and health. Those are the three things that we typically solve for our customers.

(Joel Beasley at 00:09:00) So if people are experiencing that right now and they're looking for solutions, they could call up Hatica and be like, hey. Show us what you've got.

(Harish at 00:09:07) Yep. That's pretty much how it goes. Obviously, you know, as you get into the depth of things, it gets fun. So this happened actually yesterday. So we integrate with, you know, communication collaboration tools as well. And one of our customers was saying, you know, we know our engineering team is really good. Right. And no engineering leader would say otherwise. Right. My team is the best, but it just so happened that for the last eight weeks, we've not been able to deliver more than 50% of what we planned. And that's obviously, you know, unfortunate. So we sort of went down this rabbit hole. Hey, are the product managers not defining things properly? Or are the requirements too complex? Is there something new that's come up? So we went down that whole path and turns out engineering people are spending four hours a day in meetings. Right? And this was an absolute shocker. They had no idea that engineering was spending so much time in meetings and, um, getting out of the meeting, you know, out of this conversation, they immediately rolled out a no-meetings policy. And two weeks after that, they were back on track. They were at 80% delivery velocity. So small things like that, which you just wouldn't assume is happening. And obviously, great engineers, they just fall prey to meetings.

(Joel Beasley at 00:10:29) So will you look at my Google calendars of my engineers and tell me if they're over-met?

(Harish at 00:10:35) Yes. Yes. But the whole idea here—the whole idea here is obviously we don't want to be micromanaging this whole situation. We don't want to be like this big boss thing. But the whole idea is to be able to provide this analytics to engineering teams, to developers and empower them to make better choices. We also know, you know, a lot of developers block their calendars, right? I'm just going to block four hours on my calendar so I don't get meetings. So we're smart about that. We skip that. We ignore those meetings saying, yep, that's good. That's focus time. We encourage more of those, you know, block your calendar, do your work, versus block your calendar and do meetings.

(Joel Beasley at 00:11:13) Well, yeah. A 100%. I do that. Yep. It's—every time we do something new, being the CEO, my sales team or marketing team comes to me and they say, hey. You've got no availability on your calendar to meet. I was like, well, yeah, because I'm doing good work. And so we always have to carve out special time. And so that's interesting. So I could actually see if there's been increase in, you know—because as an engineering leader, it would be interesting to see, you know, total meeting time over time. And you could actually, you know, see maybe—get a new manager, especially if you have thousands of people at your company. Right? Maybe a new manager comes about and all of a sudden, all the engineers just tripled their meeting time in this one section of the company. That would be an important—I get—I get you're in a hard position because often people's minds will drift towards authoritarian type tools. But I completely get it. Like, I want metrics and a dashboard and analytics coming at me, and then I'm just going to arrange that as I see fit. Nope. That metric's not useful to me. Don't show me that. That metric is useful to me. Show me that. And so you can customize everything inside of Hatica?

(Harish at 00:12:23) Yes. And, obviously, there's no dearth of metrics. Right? We have data from calendar, from Jira, from GitHub. So there's no dearth of metrics. The question is, which ones are important for you at this time and then what are you going to do about those? I mean, you potentially cannot optimize for all the metrics all the time. So you pick your battles, pick one, two, three things, you know, go fix that. For example, if you've hired a lot of developers, your focus needs to be on how quickly can they be productive, how quickly can they code. Or if you have a team that's struggling to release things on time, you probably want to focus on improving your DevOps maturity. You probably want to implement some tooling or systems there. So, you know, the end-to-end cycle time reduces. So depending on the stage and maturity of the company, the priority shifts. And that's okay. That's pretty much how it needs to be.

(Joel Beasley at 00:13:21) Yeah. Do you have a free trial on the website? Or how do people get involved with just taking that first step?

(Harish at 00:13:29) Yes. So for customers, there is a free plan. They can go to hatica.io, which is our website, and there is a free plan that they can access. And then, of course, we also have higher end, you know, paid plans, which we are happy to help our customers walk through.

(Joel Beasley at 00:13:45) Oh, nice. So people can just go, click on it, and just immediately start—

(Harish at 00:13:49) Yep.

(Joel Beasley at 00:13:50) Working on it.

(Harish at 00:13:50) Pretty much get started immediately.

(Joel Beasley at 00:13:53) Oh, nice. What's your favorite part about the software? I know you're probably going to think about something that's not released yet. But make sure that you can talk about it publicly. What's your favorite part about Hatica?

(Harish at 00:14:03) Yeah. Actually, the favorite part—we actually just released it last month, to be honest. It's actually, you know, we call it the Sprint Performance Dashboard. So when you think of engineering teams, they all run sprints. And at the end of a sprint, you know, they're running a sprint retro. And more often than not, the retro tends to be very qualitative. There is a lot of conversation about how much, you know, did we plan? How much did we deliver? But that's not the majority of the conversation. The majority of the conversation goes into what we could have done better. Right? And in our product, we support a bunch of signals. So we basically pull data from all these systems, and we can pretty much generate a summary of how your sprint went across qualitative metrics. Obviously we can do the quantitative part, but we can do a lot of qualitative metrics. Things like, you know, did you have issues that were not part of the sprint when you started, but they got added into the sprint during the middle of the sprint? Engineering teams hate it. They absolutely hate it when something unplanned comes in the middle of the sprint. We auto-detect that and that's part of the—that's one of the signals we report on. And there are many such signals. This one is one of my favorites. Second one is, you know, the code is done. The entire piece of code has been written, but it's not been merged because it's stuck for review. Right? And that's a big pain for developers because they need to write code, they need to get it reviewed, there will be comments, and then you merge it and release it. Right? So these are just two of a dozen-plus signals, which we actually summarize in our Sprint Performance Dashboard and just makes it so powerful for engineering teams to look at this data and have the conversation on the back of it.

(Joel Beasley at 00:15:52) And what is something that you've learned? So you've been in engineering, you've been in product, you've been around this space. But now that you're building tools specifically for these engineering teams and you're seeing a large variety of engineering teams across multiple industries interact and work, what was some new insight that you've gathered since starting working at Hatica?

(Harish at 00:16:12) Yeah, this one actually blew my mind. I used to believe that engineering teams, engineering leaders would know all these things that you're showing them. Turns out that's not the case at all. Let me give you an equivalent.

(Harish at 00:16:27) So what CRM does for salespeople is it tells them, you know, these are the deals you're working on. This is the value of the deal. This is when it's expected to close. There is complete transparency. There's complete visibility around it.

(Harish at 00:16:41) Engineering teams have nothing like this, absolutely nothing. So engineering teams are incredibly blind on their own selves. So when we show some of these things, when we have some of these conversations with engineering leaders, it's almost like, you know, we've removed the blinders that they were wearing. And if you look at some of the conversations we've had, like how much time is engineering spending in meetings? Oh, I never thought of that.

(Harish at 00:17:11) How much time does it take for your developer to release something in production? I think it is— No, no, you don't have to think. You can answer this question, right?

(Harish at 00:17:21) Or how much time do your teams spend waiting on other people to review code? That's a good question, but I don't know. So basic engineering hygiene questions are not asked and therefore not answered. That's been my single biggest learning. I would not have believed that engineering teams who basically live in data, who speak in data to product teams, to business teams, to end customers, they're this data blind about themselves.

(Joel Beasley at 00:17:50) So when they don't know the answers to these questions, how much time are my engineers spending in meetings? Is there a backlog or is there a delay in code review? Is that a problem in my pipeline? When they don't know the answers to these questions, what are they tracking? Because they're tracking something, right? They're tracking their work somehow, whether they're using, you know, Jira or whatever it may be. So what do you find do most people know? Even if it may not be that useful as far as understanding the business and productivity, what numbers do they often know?

(Harish at 00:18:27) Yeah, actually, this is a fun line of conversation. Engineering leaders shudder. You know, they really are scared of going to a conversation where these kind of questions come up. So most engineering leaders have their own presentation formats, their own status update formats.

(Harish at 00:18:49) Usually, extremely verbose, you know, heavy on text, not really very data oriented. So you would have data like, you know, how many Jira tickets did we close? What's my uptime? What's my number of severity zero issues or incidents that occurred? There is data on those which is obviously there.

(Harish at 00:19:12) But on the core engineering execution, not a lot of data gets reported. In fact, we are actually putting together a PowerPoint deck, a PowerPoint template which we basically, you know, give out to engineering leaders and say, if somebody asks you for an update, this is what you give. You fill these five slides and send the data out.

(Joel Beasley at 00:19:32) Oh, is that available today?

(Harish at 00:19:34) It is. It is. It is. It is on our website.

(Joel Beasley at 00:19:36) Where is it on the website?

(Harish at 00:19:38) I'll send out a link. I'll send out a link.

(Joel Beasley at 00:19:41) Perfect. Yep. I'm looking at your website now. I actually have it up. I want to know about async stand-ups. What are asynchronous— I mean, I know what asynchronous stand-ups, I know what the phrase means, but what does it actually look like in reality?

(Harish at 00:19:54) Yep. So let's play this through, right? So let's say you're an engineering manager and you have a team of eight developers and you do a daily stand-up, right? And everybody has to answer three questions.

(Harish at 00:20:06) What did you do yesterday? What are you planning to do today? And what are you blocked on? Just three questions that everybody has to answer. If eight people have to answer 24 questions, and even if they're really, really quick, you're up to thirty minutes. And this is just talk time. No discussion. No conversation. What happens as a result is a fifteen-minute stand-up ends up being a half an hour, forty-five minute stand-up, right?

(Harish at 00:20:32) So what the asynchronous stand-ups feature does is we send these questions out. Obviously, the questions are configurable. We send these questions out on Slack. People can, you know, respond to their questions, to these questions. We summarize the answers, and then everybody goes through the answers in the conversation.

(Harish at 00:20:49) So the stand-up ends up being a review of just the last question, which is what are you blocked on? Right? Focus on that and then help the team move forward. We actually built it for the pandemic period when a lot of teams were distributed. But then the feature is just so popular, you know, we are able to get it across to all our customers even today because a lot of teams are still either remote or at least they are hybrid.

(Harish at 00:21:07) So that's one part. The other thing which we are able to do is we actually don't need the teams to tell us what did they do yesterday. We can pull that information from GitHub, Jira, and other places. So the answers essentially are pre-populated. You can just modify the things that you couldn't accomplish yesterday.

(Joel Beasley at 00:21:38) And this is available today?

(Harish at 00:21:40) No, the last part is something that's coming soon. In a couple of months, we'll basically be releasing the entire stand-ups done by us.

(Joel Beasley at 00:21:49) Okay. But is part of the asynchronous thing done today? Okay. And so I can just go sign up and get a trial and play with it?

(Harish at 00:21:58) Yes. Yep. That's part of our free plan.

(Joel Beasley at 00:22:01) Okay. That seems like it's almost its own product. That's actually pretty cool.

(Harish at 00:22:07) It is.

(Joel Beasley at 00:22:07) You know, my next thing as a manager is okay, now— So I ran something similar. So we make our show, but then we make about 20 other shows. So we make shows for other brands, right? So we have different shows and they all have editorial calendars and they're all tracked and everything.

(Joel Beasley at 00:22:21) And I was talking with my head producer and I said, hey, you know, I want an update. We do this every week of all the different shows and where they're currently at and answer these three questions about each specific show, right? Because sometimes customers can— We also want to track not only just the hard metrics of deliverables, but like, what their current state is. Like, if they're happy or they're frustrated or whatever it may be.

(Joel Beasley at 00:22:43) And so we're getting enough clients now that me reviewing 20 of these deals every single week and reading all about them, I'm like, man, why can't I just paste this whole update into ChatGPT and tell me, you know, show me the two or three deals I need to focus on, you know, because it's— What are we going to do when we have a hundred, you know? And so it would be really great if when you're doing those stand-ups, they could somehow figure out like, which are the most important ones to bring up to the man— Like, from a manager perspective. I'm managing a team of five and everybody's going to be answering these questions on a daily basis. Like, it would be great to have this filter system that would pop up the most urgent stuff to the top. Because as you know, you aren't guaranteed to get through every single one of them in every single conversation.

(Harish at 00:23:28) Right, right.

(Joel Beasley at 00:23:29) So putting the most important ones first would be interesting.

(Harish at 00:23:31) Right.

(Joel Beasley at 00:23:32) Do you guys do anything like that yet?

(Harish at 00:23:33) No, it's something that we're planning on, actually. It's something that we've considered quite a bit because, as you said, you know, for the engineering manager or for the person running the scrum, unblocking the team is the most important thing. And if, you know, if there are 10 blockers, you probably can't unblock all of them. But if we could prioritize that, hey, this has the single biggest impact on your sprint, that would be really awesome. So it's something that we're very much considering.

(Joel Beasley at 00:24:00) When companies are looking at it from a dollars and cents perspective, right? I'm going to make this investment. It's not only the cost of purchasing— I know you have a free version, but if I get it really embedded into my teams. It's not only the cost of purchasing your software, it's the human cost of implementing it and using it and the training of it and all of that good stuff and the implementation aspect of it. So they're going to be looking at— Somewhere in the stack of the technology leadership, CTO or somewhere, they're going to say, okay, you're going to allocate this many, you know, human hours to implementing this at the company. And it's going to cost this many dollars. So collectively, it's going to cost our company this much money to make that move. Are we going to get that much money?

(Joel Beasley at 00:24:43) Like, what's the return on that time?

(Harish at 00:24:45) What's the ROI?

(Joel Beasley at 00:24:46) Yeah. What's the ROI on this? You know, how do you— Obviously, they're asking that question. I mean, I would imagine they are in these sales calls. How do you respond to that?

(Harish at 00:24:55) Yeah. Actually, it's super easy. Because if you look at any software company and you look at sort of the expenses, their number one expense and their number two expense, in any order would be engineering and cloud. Those are the two, right?

(Harish at 00:25:13) Obviously, cloud, there are a lot of— There's a lot of competition. There's a lot of things you could do to optimize your cloud spend. But when you look at engineering, you obviously don't have a lot of data, right? So the way we focus on this is we start by saying, hey, we can tell you exactly where engineering is investing. How much money is engineering spending on your iOS app, your Android app, your website, your back end? So that's one point. So it just helps you very quickly understand where engineering is investing. The second thing, of course, is can we get engineering to do more?

(Harish at 00:25:49) And that's the flavor, right? I mean, if you look at what's happening economically right now, the, you know, recessionary conditions and so on, there's no question that any engineering team has to do more. And with the advent of AI, engineering teams can also produce code faster. So the whole conversation of ROI that we have is, hey, first you need to know where your investment is going. Number two is you need to be faster in your entire cycle time.

(Harish at 00:26:17) So from the time engineering gets a requirement till the time they ship it into production, you've got to be able to crunch that. And if we can make that improve by 1% and we're talking about the first or the second biggest expense item in your P&L becoming 1% better— I mean, that's huge for companies. That's massive, right?

(Harish at 00:26:39) Between cloud and engineering wages, that's anywhere from 30 to 50% of your costs.

(Joel Beasley at 00:26:45) Wow. Yeah. Yeah. And do you have any case studies or like, super happy customers that people can talk with?

(Harish at 00:26:53) Oh, yes. Plenty. Plenty. We have a bunch of case studies on our website. Plenty of them.

(Harish at 00:26:57) Nice. And obviously, there are many more that, you know, that we are signing up for soon.

(Joel Beasley at 00:27:01) What's next? What are you guys doing that's going to be really cool? Where do you see this going? Let's say we fast-forward five years. Where do you see Hatica then? Is it just hanging out with, you know, the GitHub Copilot and they're just running engineering for everyone and the developers are sitting back eating snacks?

(Harish at 00:27:21) No, no, I don't think so. Because as you know, prompt engineering is the new thing. So everybody's got to learn.

(Harish at 00:27:26) Yeah. Everybody's got to learn how to write, you know, better prompts. But based on our conversations with customers, and this is really odd, but customers who speak to us, they say, hey, what are you doing for engineering? Could you do the same thing for QA? Could you do the same thing for DevOps? Could you do the same thing for designers and product managers, right? And these are all hard to quantify. Like essentially what we are doing is we are quantifying engineering, right?

(Harish at 00:27:55) We are basically taking down every piece of engineering and putting a number to it. But there's no reason why this can't be done for the other, you know, roles in product engineering like QA, like DevOps, and the others. So that's kind of one part that we might explore in the future. But one thing is for sure, you know, the speed with which engineering teams have moved so far, I think they need to move at least 10x faster, at least 10x faster.

(Harish at 00:28:30) Because writing code used to be extremely cumbersome. It used to be extremely difficult. You have corner cases, you have, you know, test cases, failures. A lot of these can be overcome, you know, through smarter prompts to ChatGPT or GitHub Copilot. So engineering needs to move quicker. That's the fundamental problem I see here.

(Joel Beasley at 00:28:51) I 100% agree. And prompt engineering, you're exactly right. I actually found myself writing a job post on Upwork the other day for a prompt engineer to help us write proposals and business cases for companies. And it's been fascinating. I almost got old. I almost became an old person because I saw these GPTs coming out, and I saw Midjourney coming out. And I'm just like, you know, I'm running my business. I'm making money. Like, we're growing the teams. Like, I'm focused on this.

(Joel Beasley at 00:29:25) And then I realized, uh-oh. Like, 18-year-old version of myself would be sitting around playing and tinkering with whatever is coming out and looking at all the old people saying, you guys have no idea what's coming. So I spent a couple mornings and, boy, ChatGPT— From February until now, the past seven, eight months or so— That has become a key part of our business. Very important.

(Joel Beasley at 00:29:48) Very important part of our business.

(Harish at 00:29:57) Yes. It's quite incredible. And I think somebody said this many years ago, if you don't embrace change, the technology industry is a terrible industry to be in because the only constant here is change, compared to, you know, any other industry— manufacturing, financial services, healthcare, retail. Things change, but not the rate at which they change here. It's crazy to think about how things were ten years ago, even two years ago.

(Harish at 00:30:24) Who would have thought, you know, AI would change our lives so much two years ago? I mean, at that point, the greatest thing was still microservices, serverless computing, cloud, machine learning. And here we are two years later, nobody's saying these things.

(Joel Beasley at 00:30:38) I know. Because it's so— It's so crazy how good the technology is.

(Harish at 00:30:44) Yeah. I think there's no limit to how far we can go as a population. And I think that's the thing. So this AI thing is probably a blip in the hundred-year history of computing, but it's a significant blip. It's a significant blip.

(Joel Beasley at 00:30:57) Well, this is great. So our next conversation will be in twenty-five years in the Andromeda galaxy. You and I will meet up at one of the coffee shops.

(Harish at 00:31:05) Yes, we shall. Hopefully, the audio-video would be a lot better.

(Joel Beasley at 00:31:09) Yeah, 100%. Yes. Or, yeah, we might just teleport at that point in time.

(Harish at 00:31:13) So who knows? Yes. Beam me up.

(Joel Beasley at 00:31:17) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.