Episode 399 ·

Jay Mehra, CTO of Odessa - Staying Nimble Long-Term

Today we’re talking to Jay Mehra, the Co-founder and CTO at Odessa. And we discuss what it was like starting the company out of a dorm room in the late 90s. How to avoid building monolithic tech and stay nimble long-term, and why it’s important for entrepreneurs to think first about increasing revenue rather than cutting costs. 

All of this, right here, right now, on the Modern CTO Podcast!

To learn more about Odessa, check them out at https://www.odessainc.com

About Jay Mehra:

Jay Mehra is the co-founder and CTO of Odessa, a technology company serving a diverse customer base of leasing companies globally. Odessa provides powerful, end-to-end, extensible solutions for lease and loan origination and portfolio management. The platform further provides rich feature sets including low-code development, test automation, reporting and business intelligence to ensure organizations can more effectively align business and IT objectives.

About Odessa:

Headquartered in Philadelphia, USA, Odessa is a software company exclusively focused in the leasing industry. The Odessa Platform powers a diverse customer base globally, providing end-to-end, extensible solutions for lease and loan origination and portfolio management. Odessa facilitates business agility through rich feature sets including low-code development, test automation, reporting and business intelligence to ensure organizations can more effectively align business and IT objectives.

Transcript

This is the Modern CTO Podcast.

(Ashish Shastry at 00:00:13) The way this works, because I actually went to college in the States. I am currently based in Bangalore, India. So I actually, and I have been living here for many years. I went to college in the States and studied economics and math, stayed as far away from computers and computer engineering as I possibly could.

(Joel Beasley at 00:00:34) That's not that far.

(Ashish Shastry at 00:00:37) And then, yeah, you know, I actually, I had gone to high school with a very good friend of mine who now currently is Odessa's CEO. And what happened was he was in the U.S. at the same time as well, and he actually through an internship worked with a company that ended up, then as it turned out, doing something very similar to what we do, at least in our early years. So when he decided to kind of start Odessa, he gave me a call. And I've obviously known him since childhood, so I think he told me, "Hey, listen. I'm trying this thing in this pretty niche industry. It's an asset finance industry. Would you like to join me?" And I think I thought about it for one second. We were still in college at the time. And I think my only response was, "Cool. Whose dorm room should we work out of?" You know? So that's actually how I got into technology. Obviously, I had some idea of just engineering, computers, and how that comes together. But that was really how we got started. So it's just the two of us for quite a few years, and that was how we learned the craft.

(Ashish Shastry at 00:01:38) We made our way through.

(Joel Beasley at 00:01:44) That's awesome.

(Joel Beasley at 00:01:46) So did you grow up in the Bangalore area and then go to school and then come back?

(Ashish Shastry at 00:01:50) Actually, no. I grew up in Mumbai, which is, I don't know if you know, it's just an hour, hour and a half flight, so it's further up north in India. But Madhu, who is our CEO, and I actually met in high school, which is in another part of the country.

(Joel Beasley at 00:02:06) That's really cool. That's awesome. Because it's really cool how you never know what relationships you make at any point in your life.

(Ashish Shastry at 00:02:15) Yeah. No. No doubt about it.

(Joel Beasley at 00:02:18) So can you tell me a little bit about what—so Odessa has pretty much been your only job in your career, right?

(Ashish Shastry at 00:02:24) Absolutely.

(Joel Beasley at 00:02:25) That's awesome, man.

(Ashish Shastry at 00:02:27) Already unqualified to do anything else, really. Made us certifiably unemployable, I think. But yeah. So it has been the only job. Because the way we started was obviously the sort of classic dorm room kind of just working through whatever we tried to do, scraping things together, and trying as hell to get someone to buy our software. So we started with, and I'm going to definitely date myself here, but we started with essentially what you today would say is a glorified Excel sheet that helps salespeople who were selling equipment finance out in the field to calculate your sort of buy versus lease calculation. But the kind of significant innovation we had there was that it also printed your documents. So, you know, the salesperson could go and then he or she could connect to a printer and print the documents. So it was almost like an early presentation, sort of mobile type application. The whole idea was that because you could print it, that was really the innovation that we had. Otherwise, salespeople had to go back to the head office and, you know, do it and so on. So that was the difference, really. And I think that just got us going. We sold a few copies of that, and that's how we got momentum. Then we made the shift to start building over the very early stages of what is our current platform. So that was kind of how the journey evolved.

(Joel Beasley at 00:03:50) That's crazy. That's filling such a simple need that was clearly unmet.

(Ashish Shastry at 00:03:56) And that was really, you're right. You know, you make a good point, Joel. That was really the learning. The learning was because we didn't actually, the first iteration of that software didn't really have that print document capability, which was the magic capability. People were paying, I mean, just to put it into perspective, people were paying $3,000, $5,000 a pop for this thing. So it wasn't like it was, but it absolutely paid the bills and put food on the table and so on. So I think you're right, though. The insight of, hey, if we get this in the hands of the customer and then you come back and you learn one more thing that they want, you can just keep iterating that way. That was, I think, the biggest learning through that, to be honest.

(Joel Beasley at 00:04:34) So when it started, it was a software that helped salespeople that are selling equipment finance. Right?

(Ashish Shastry at 00:04:42) Yes. Exactly. So if you imagine, for example, someone's going to a farm, a salesperson's going to a farm and saying, you know, don't buy this combine or tractor. Why don't you lease it from us instead? And here's why the economics of that will work better. So it was something you could probably do on an HP-12 calculator, but the idea here was that you could also print the documents. And that was the magic insight that we had. At least, it got us started.

(Joel Beasley at 00:05:09) So what's the company doing today?

(Ashish Shastry at 00:05:13) So we're still in equipment finance and asset finance, but now, obviously, the scope and the remit of what we do is much broader. So what we do now is we manage the end-to-end life cycle for an equipment finance or an asset finance contract. So if you think about what happens in terms of how a lot of capital equipment gets procured, maybe if you're a little bit removed from the industry, your take is when a piece of equipment gets bought, it actually gets bought. But so much of it, I think seven out of 10 pieces of capital equipment in the U.S., for example, get financed. And so it's a massive industry. It's about a $3 trillion industry in annual volume. So industry insiders will tell you, you know, it's the trillion dollar secret in the U.S. that nobody knows about. Right? So the way that works is you go through the entire sort of life cycle of putting in a credit application, being adjudicated for credit, funding, disbursement of that loan or that lease of the monies, the delivery of the equipment, the managing of the billing, the accounting, and so on. So it's a very comprehensive process. So what we do is we manage that end-to-end life cycle. So we're really, if you're an equipment finance or an asset finance organization, we are the heartbeat on which your entire organization runs. And then, of course, that's the core of what we do, and then we have a platform that sits around that that allows you to do much more, manage your data, have an omnichannel presence with our customers' customers. So we help digitize that relationship and so on and so forth. So that's really what we do. So it's grown quite a bit from that calculator, but it's in the same general area.

(Joel Beasley at 00:07:02) Okay. Cool. So I'm curious. What's the benefit of having expertise specifically in equipment finance? Like, why can't a bank run this kind of operation as they would for, like, other types of finance?

(Ashish Shastry at 00:07:17) No. A bank does. The bank would be our end customer. So the bank is, the bank runs our software, and on the back of that software runs its operations using our technology. So the bank does run it, but they use our technology to run it.

(Joel Beasley at 00:07:36) Cool. Alright. Alright. This is clicking for me a little bit. One thing I always like to ask founders or people that are on the ground floor, where did the name come from for the company?

(Ashish Shastry at 00:07:49) That's weird. We always get, I'm surprised you took that long to ask. So I think, so we were both readers. Madhu, who's our CEO in particular, loved The Odyssey, which is, you know, the Homer story about The Odyssey. So we actually started the company by calling it Odyssey International, which sounded more like a cruise ship. You know? I think go from Florida to Jamaica on the Odyssey International. So then we changed it almost overnight, and then the name evolved to Odessa, which is the manifestation of the journey. And, you know, that was a very important part for us. In fact, still kind of in our values, which is, you know, enjoy the journey. And that was actually the whole reason we did it in the end. It wasn't necessarily particularly that we wanted to revolutionize asset finance only. We also wanted to just be in it for the ride. And it's been 23 years, and we're still on that roller coaster.

(Joel Beasley at 00:08:48) Nice. So I guess, what were some of the challenges you came up against early on? Because, I mean, founding a company is hard.

(Ashish Shastry at 00:08:58) Yeah. It was. It was hard. I think the big thing was just, so the market that we work in, and to some extent is still the case, it's dominated by legacy technology, a few players. There's significant barriers to entry to enter this because these are very important middle office, front office, and back office systems that run the heart of very complex operations at these large financial institutions. So it's hard to actually have credibility in getting this. So the hardest thing was to try and win the trust of the prospective customer for them to take a chance on a relatively new player. So I think, again, that came from, you know, obviously, you just keep trying and you keep trying to attack one piece of insight that you feel that will make the difference. So you win your equipment finance calculator, and you print the documents, and you just kind of build from there, and you keep going. And then there's just somebody who then eventually decides that they want to take a chance on you. But I think that process is difficult, of course. And we were, you know, we were a bit old school. We didn't go out and get money and get funding and so on and so forth. And also, we were both immigrants living in the U.S., so that made it a little bit harder to do anyways in those days at least. So all of that meant that we had to do everything sort of organically, which was great in one sense because it taught us to eat only what we killed and not get ahead of ourselves and so on. But it also made things, it also meant that things took a little longer to get off the ground than they would. And certainly, the ecosystem to help someone who's starting a new company now is so much better and so much more active than it was in those days for us, at least. But that was the, I think that was the hardest part. Of course, along the way, you have a lot of bumps. You know, things that you remember that stay with you, prospects that you should have won that you didn't, deals that you lost, you know, software that you put out there that didn't quite work. All of that comes with the journey, but I think the hard part was just getting that initial credibility with customers.

(Joel Beasley at 00:10:57) So I'm sure that there's a lot more advanced tech behind it today than the option to print. What's some of the tech behind your product today?

(Ashish Shastry at 00:11:07) Yeah. So we are, actually, we are a Microsoft shop. So our technology stack is primarily a Microsoft technology stack. A lot of emphasis on, so we use a lot of .NET, C#, and then, of course, Azure on the cloud side. So that's the general technology stack that powers our software.

(Joel Beasley at 00:11:30) Cool. So I saw this phrase on your website that you've externalized your solutions into a low-code platform. Can you expand on that? What does that mean in practice?

(Ashish Shastry at 00:11:44) Yeah. Absolutely. So just maybe a little bit of context there. Right? So for us, you know, obviously, we've gone through many iterations and sort of versions of our technology. When we were working on what is now our current generation platform, the one insight that we had from years of doing this before is that we have to focus on developing the right framework to do the development of the domain work that is associated with the equipment finance and asset finance industry. So what I mean by that is we said, "Okay. We've got to build a factory, and then we've got to build a car in that factory." But the focus was on developing the engineering framework that supported that. And so we went through that process, and we built the car. And then through that process, we realized, hang on. There's actually a product hiding behind this entire car, which is the factory itself. So what we did is we also productized the factory and then gave our customers the same flexibility that our engineering teams have to extend and modify and alter the platform. So that became a very important part of our R&D philosophy, really, which is, you know, eat your own dog food or drink your own champagne or whatever you want to call it. But the idea is that we build a lot of the tools and frameworks and the ecosystem technology that supports the very thing that our customers use. We consume it ourselves. So we're the first customer of our own toolset. And then if we can externalize it and give it to our customers, then you have already a validated product that our customers can use and leverage. And then it gives us a structured mechanism by which we can actually engage with our customers because the technology framework or the paradigm is exactly the same. So from a technology perspective and even from a business outcome perspective, hopefully, we're then talking the same exact language. So that's what it—

(Joel Beasley at 00:13:49) So what are you guys using your own product for internally?

(Ashish Shastry at 00:13:53) So we use our own product for many things internally, but primarily for building our core system. So we have a core system, and then we have a development framework that sits underneath it. And all we've done is we've externalized the development framework so that our customers can take our core system and, as I said, just modify it. We use our core system and we use our, sorry, our development framework. We continue to expand it as well so that our customers can use it as a low-code development platform. So what we find in these very complex implementations that we do is we have a customer that has core needs across the asset finance life cycle, but also other software that sits around it that they want to rationalize, homogenize. So they use our low-code framework to do that as well so that we then become sort of the operating system on which the entire organization runs as opposed to just this product that they black box and put in a corner and use for things like accounting and billing and credit. That's the platform sort of thinking. So maybe if you had that conversation five years ago, the same conversation five years ago, you would have said, we build a product. But today, it's very different. We build a platform.

(Joel Beasley at 00:15:04) Got it. So you've kind of created, like, an open source ecosystem with your clients.

(Ashish Shastry at 00:15:09) That is correct. That would be the equivalent.

(Joel Beasley at 00:15:12) Okay. Cool. So it's like, but it's not technically open source. It's just the people that have it can modify and work on their copy. And then you can implement cool changes that they make if you want to on the product side. Is that—

(Ashish Shastry at 00:15:29) That's right. One of the challenges, one of the things that we have to solve as an organization is our customers want a core standard system that does a lot of things that are very important from a process standpoint, from a regulatory standpoint, from an operational standpoint that is common across asset finance in general. But then they also want last mile flexibility to do things that are unique to them. So that is really the problem.

(Ashish Shastry at 00:16:01) That's the problem that we're trying to solve, or that's the business outcome we're trying to drive to, which is how do you have a standard platform that does maybe 85, 90% of what you do is common, but then how do we give you that last mile flexibility? So that development framework that we've externalized allows our customers to self-serve and get that last mile flexibility if they need to. That's the beauty of kind of how that comes together.

(Joel Beasley at 00:16:26) And so you also said that the development framework is low code. And I know low code is a bit of a spectrum in terms of how low, I guess, it is. So does the end user have to be a developer to use it, or what kind of experience level is required?

(Ashish Shastry at 00:16:46) Yeah. I think in this context, you do have to be a developer because you're ultimately working to extend or modify a reasonably complicated accounting operations system. But in terms of just design and prototype, you could certainly be someone without development experience. But if you're really going to start making changes, then you do have to have some development experience.

(Ashish Shastry at 00:17:13) So we have to get a balance, making sure that, for example, someone can prototype effectively and, yes, develop code on that.

(Joel Beasley at 00:17:23) So you guys have been around for, you said, 23 years now. Right?

(Ashish Shastry at 00:17:27) That is correct.

(Joel Beasley at 00:17:28) So being around for a while now, how have you avoided falling into the trap of building some monolithic tech that becomes more of an obstacle than something that enables you? Have you stayed nimble?

(Ashish Shastry at 00:17:44) Yeah. It's a great question. It's a challenge. Right? That's one of the hardest parts.

(Ashish Shastry at 00:17:49) But, for example, my job is when do you decide it's the whole innovator's dilemma. Right? When do you decide that incrementalism is gonna come in the way of moving you forward, for example? Right? So the way we tend to work is we tend to look at, you know, we have sort of two time horizons that we tend to look at the world in. One is a six to 12 month time horizon and then the three year time horizon. Right? So, you know, you do look at different sections of your entire technology landscape and saying, okay, how much can I do incrementally to continue to add value to the customer? And then at what time do I realize that, you know, I'm actually really contorting, breaking the paradigm, the architectural integrity, what I'm trying to achieve by going down this road. And then I gotta just wipe the slate clean and start over. So it's a constant investment in incremental enhancements. You gotta keep your tech debt as low as possible. And then every once in a while, you just gotta say, you know, stop. I'm going to rewrite this.

(Ashish Shastry at 00:18:51) The question really is, how do you know stop, I'm gonna rewrite this? Because anything you build from an engineering perspective, you know that at some point, you're gonna have to redo. Right? It's just a question of knowing when those signals come.

(Ashish Shastry at 00:19:01) So it's, in some sense, more important. It's important to not conflate, you know, engineering culture with engineering, because engineering can be iterative, but your engineering culture really can't be very iterative. You've got to know when you say, you know, I'm gonna throw this away, and I'm gonna start again. And you have to have the courage to do that. That's not always easy, and it's not like we've always made those decisions well, but that's something that we always think about.

(Joel Beasley at 00:19:27) Yeah. That's really, really challenging too, because if you wait too long to wipe the slate clean, then it's like the process of wiping the slate clean just becomes more and more intense.

(Ashish Shastry at 00:19:41) That's right. And I think the irony is the longer you wait, the harder it gets to wipe the slate clean as well. Right? So what happens is, you know, when do you make that switch and when do you decide that incrementalism is just not enough? Right? And I've gotta do it. Because you can't always, obviously, wipe the slate clean either. It has to make business sense. It has to make commercial sense. Time to market considerations, all those things.

(Ashish Shastry at 00:20:02) So just the other day, we were, you know, I'm sure you're familiar with Martin Fowler, for example. We were just looking at one of his design paradigms around a strangler tree, which is, you know, apparently, this tree in Australia that grows, but it uses the base tree that exists to grow and then strangles the base tree out of existence. And that's a design paradigm that we were thinking about using for some parts of our technology landscape that we wanna modernize, but we can't throw away. So, again, finding that balance between, you know, how hard you push incremental innovation versus full, disruptive change is something that is one of the more challenging parts of my job and, really, our engineering team.

(Joel Beasley at 00:20:48) Did you have any failures around this early on that you really learned from?

(Ashish Shastry at 00:20:54) Many. Many. You know, you look back, and sometimes there are occasions where we said, for example, at one time we had a perfectly well-functioning piece of functionality, which we then decided, you know, we're gonna change. It's on slightly dated tech, and we wanna go ahead and change it. And we did that. And, frankly, we didn't get the business outcomes that we were expecting in that. Maybe what we had done before was actually generating equivalent business outcome from even if you just look at basic things like revenue and so on. Right? And you realize that you don't get the outcomes that you want. And you then realize, you know, you chased technology for the sake of technology. You weren't rooted in the business strategy. So that happens. We certainly had our fair share of those. Sometimes the engineering voice becomes louder than the business voice, and you've gotta manage that. And then there's equal examples of it going the other way, which is, you know, we should change that faster. We should have thrown it away earlier. And then that happens as well. You know, I think 23 years, we're littered with examples of when we've done that, but it's always just finding that right, that great rhythm and balance to it.

(Joel Beasley at 00:22:10) Yep. And learning from each one. I'm sure you're much better at it today than you were when you were working in the dorm room.

(Ashish Shastry at 00:22:17) Yeah. No, no, no. I think one thing I've learned is in some sense, when you're leading even when you're leading an R&D organization, you almost gotta think about it more like a CEO than a CTO, in that you gotta think about it as a business function first and almost separate the solutioning from the technology. So sometimes engineering teams tend to think a little more about what technology should we use to do this? What technology should we use to do that? As opposed to, okay, how are we achieving what the customer wants? Right? And so it sounds simple, but it's very important to come and kind of come back to that first principle sometimes when you're making those types of technology decisions.

(Ashish Shastry at 00:22:57) So why I said think about it sometimes more like a CEO, because if you think about the marketplace, you think about the customer, you think about being rooted in business strategy, then, generally, the solutioning, you know, then falls into place, and the technology enables that solutioning as opposed to flipping the other way around. Where you're almost a solution looking for a problem. And I think we've learned that, you know?

(Joel Beasley at 00:23:25) Yeah. You wanna not have tech for tech's sake?

(Ashish Shastry at 00:23:29) That's right. Yeah.

(Joel Beasley at 00:23:31) So I'm curious. I saw you have on the website, there's an Odessa Foundation and an Odessa University. First, can you tell me a little bit about the Odessa Foundation?

(Ashish Shastry at 00:23:44) Yeah. I think that was a pledge that we made about five, seven years ago, just around what we give back to our community in terms of money, in terms of time, and just how we participate more broadly in the world that we live in. We are quite a global organization. You know, we're about a thousand people now. We operate in different geographies. A large portion of our operations are in the US as our headquarters. India is a large portion of our operations as well. So how can we give back to just the community that we live in was a very important part of what we wanted to be. Frankly, when we got to the point where we had the means and the resources to do that, it was a very important thing for us to kind of put our money where our mouth is in terms of what we wanted to do for the world at large. So that's what the Odessa Foundation is.

(Ashish Shastry at 00:24:37) Odessa University is a different thing. Odessa University is really our boot camp, our learning institution for engineers, analysts that join our organization. So how do we take someone who joins the organization and get him or her up to speed quickly around what we do, learn our frameworks, learn our tools, understand our domain, and then, obviously, keep that, as far as possible, a continuous process. So it's really in-class training, one-on-one training. It's classroom training. It's resources and aggregation of all our knowledge, all our retros, everything we've learned, all the mistakes we made, all the good things we've done that you have access to. You work at Odessa so that you can continue to learn and continue to innovate. We also partner with different groups in the leasing industry. We're very invested in how the leasing and asset finance industry works. So we partner with the leasing industry to kind of develop those training courses as well. So that's really what the Odessa University encapsulates.

(Joel Beasley at 00:25:43) That's really cool. So continuous learning is a big part of your culture.

(Ashish Shastry at 00:25:48) It is. And, you know, again, it's one of those things where you look at it and every time you look at it, you feel we should do even more because just the benefit, business, morale, everything is true.

(Joel Beasley at 00:26:02) That's awesome. So do you have any full-time instructors on staff, or is it some of your? Oh, cool.

(Ashish Shastry at 00:26:10) No. We absolutely do. We absolutely do. We have full-time, we have a full-time training team, instructors with everything from database technologies to, you know, Microsoft technologies to accounting, leasing. All of that is all part of our full-time staff.

(Joel Beasley at 00:26:26) That's awesome. What we do here.

(Joel Beasley at 00:26:28) And so is that also tied in with advancement at the company? Like, if you are interested in taking on this new role, you can take this class and upon completion, you're now eligible to move up in this way. Is that a part?

(Ashish Shastry at 00:26:45) We're not as prescriptive about that in terms of, you know, this is a benchmark. This is a prerequisite to get you to the next level of promotion cycle or whatever it is. We tend to look at it more as learning and knowledge for learning and knowledge's sake and not necessarily tied down with, I think, professional development from the point of view of what it means for your promotions and so on. Of course, it's professional development for the sake of the journey, coming back to the Odessa principle. Right? It's for the sake of the journey. So we keep it more open from that perspective, and that's really the philosophy that drives it.

(Joel Beasley at 00:27:22) That's awesome. So on the topic of culture, one thing I've been thinking a little bit about. So recently, I interviewed this guy, Mark. He's the CTO of a company called MongoDB. And they're in the database space. They're making cool stuff, making databases faster and more efficient and easier to use. But he was talking about how their culture is very open and they communicate with a lot of their employees on their higher-level organizational strategy to get feedback from the frontline employees and engineers to understand if their higher-level organizational timelines are realistic. And they'll make changes to their strategy based on the feedback from their employees. So I'm curious, how do you get feedback from or keep open communication with your employees?

(Ashish Shastry at 00:28:17) Yeah. Lots of ways. I mean, we start with the basics, town halls, webinars. You know, we have a full-time comms team that does actually a very good job in terms of communicating on a weekly basis about what's going on with the company, new wins, day in the life of kind of blogging from different people in the organization, and so on. So those are, you know, that's one kind of level of or one type of information radiator, information radiating that happens in the organization.

(Ashish Shastry at 00:28:49) The other thing that we use is we have a, we use OKRs as our, you know, to define our North Star, to define our goal-setting framework, and so on. And so we have OKRs that obviously live at the organizational or the corporate level, and then we cascade those OKRs down to individual teams. And then, obviously, ultimately, to employees. Every single person in the organization has an OKR associated with him or her. Now all of that is available on our internal wiki. So the organizational OKRs, for example, organizational OKRs, our CEO's OKRs, my OKRs, and then every single person's OKRs are available for everybody to see. So that's another mechanism by which we hope that we have that sense of transparency and then, of course, alignment about what we're trying to achieve as an organization. And the other thing we do is we score them at the end of each quarter. Right? And they're scored not by, for example, it's not that our CEO and I score a department. The department leads score their own department, and no score is questioned. You put whatever score you believe is the correct score for what you've achieved. Right? And similarly, from an employee perspective, you score yourself on those OKRs. So the whole idea there is also that it's all, again, learning and development for development's sake. We don't tie those to your performance reviews or things of that nature so that you're really trying to develop and align your North Star with the organization's North Star, whatever personal ambitions and goals that you have. And yet you try to do that in a safe way, and it's not tied with, you know, what I'm gonna get as my raise or what I'm gonna get as my next promotion cycle and so on. Because once you, if you decouple those things, we found that they're much more powerful. People will put a stretch goal in there, for example, and be honest about where they feel.

(Joel Beasley at 00:30:45) So having that full-time comms team and also a full-time training team, sounds like you guys do a lot of investment in the culture at the company, which sounds awesome for working there. But I'm curious, do you have any KPIs that you use to measure the return on this investment in the culture at the company?

(Ashish Shastry at 00:31:05) I think from a KPI perspective, one of the things that we do do, for example, if you join the organization at college, right, and, you know, maybe you're familiar with some of the more theoretical aspects of computer science and engineering, but you haven't worked out there in the real world, right? So we go through—you go through our sort of boot camp, our orientation boot camp that is associated with learning our tools and our technologies and our domain.

(Ashish Shastry at 00:31:34) And then we onboard these people onto actual programs once that is finished, right, once that process is finished. So what we then do is we measure just, you know, it could be a simple dipstick test to make sure how these—in, say, fifteen days after you've joined a program. Let's assume, Adam, you went through that. You came out of college. You went through that boot camp.

(Ashish Shastry at 00:31:56) It's about a fifty-day boot camp. You come out of that fifty-day boot camp. You start writing code, right? Fifteen days in, we check in with your team lead to see how you're doing, and then we do another check-in forty-five days, and then we memorialize all that formally in ninety.

(Ashish Shastry at 00:32:11) And that gives us a sense of, well, have we hired the right person? Is our training right-sized? Because sometimes our team leads will come back and say, you know, whatever we teach in those boot camps is not necessarily exactly what we do right now. So we go back and iterate with our training teams, or it may inform how we hire somebody, what expectations we set with someone when we hire, right, at college, for example. And then also, if we feel that people have onboarded well.

(Ashish Shastry at 00:32:35) So we have a scorecard about how each person has onboarded. It's a pretty simple scorecard. And that's where we know, okay, if we get 70 or 80% of the people have onboarded well and their managers feel they're doing fine and they're contributing to the team, then we know that everything that comes before it is working. So that's sort of how we measure the success over there.

(Joel Beasley at 00:32:53) Man, that's awesome. So from thinking about, like, when iterating on the tech or iterating on the training or keeping a finger on the pulse of the leasing industry, it sounds like you wear a lot of hats in terms of what you have to think about on a daily basis. I guess, so if you had like a pie chart of how you divide up your time day to day, what does that look like?

(Ashish Shastry at 00:33:20) Yeah. I mean, everything I just described, I should say that we have teams and people who do, you know, just it does not fall in.

(Joel Beasley at 00:33:27) But, I mean, it sounds like you're thinking about all of it a lot, you know, and—

(Ashish Shastry at 00:33:30) I think that's very important, right? Yeah. I think you're—you know, what I've learned or I think what we've learned as a company through the years is, you know, most structures work when you scale. If you have something that works for 100 units of a thing, let's assume it works for a hundred people.

(Ashish Shastry at 00:33:47) You can use that same structure to kind of scale it to 200, but when you start getting to three x and four x, that same structure won't work. So you have to kind of try something new. But coming back to your question, I think I spend around, you know, about 25% of my time on just technology operations, just making sure that our product roadmap, we're executing correctly on it, governing it, making sure that we're delivering as we say so we're hitting our GA timelines and so on and so forth. So that's technology operations. I think there are 25% is about this product strategy, which is, you know, just thinking about where we should go directionally from an organizational perspective.

(Ashish Shastry at 00:34:28) 25% is just—you know, part of my hat is also a founder hat, so it's just running the company, customer relationships, prospecting, and so on. And then the last 25% is around the team and the hiring and just kind of obsessing about whether we have the right people in the right places, whether we have the right org design that can continually scale.

(Joel Beasley at 00:34:50) That's awesome. Thanks for breaking that down for me. So, what are you learning right now at your company? What's something that's challenging you?

(Ashish Shastry at 00:35:00) I think the biggest challenge that we have really is one of scale, right? That's the—so it's a good problem. I always, sometimes it can get exhausting, so I always remind myself and our teams that it's a good problem, right? You'd rather be trying to scale than not. But I think that's probably the biggest challenge. So first of all, you know, can we hire the right people? Can we hire fast enough? That's one problem. Again, a good problem, but it's a problem nonetheless. So that's definitely one thing that we're trying to solve for. And the other is kind of understanding the mechanics of how a team works and understanding in the guts of a scrum team, for example, what makes a scrum team tick? What makes a scrum team viable, right?

(Ashish Shastry at 00:35:47) I think that's a very important part of, at least from my perspective, what I'm always trying to think about. Having the right roles, having the right team culture. I mean, if you come back to what I was referring to earlier, you can kind of always fix engineering, but it's really hard to fix engineering culture. So that's very important that you get that right. And then I think the other problems that we're working on are just developing—So from my viewpoint, the product strategy piece is really important, but I think what's more important is making sure that we have clear measures of success, right, around what it means to launch something, for example.

(Ashish Shastry at 00:36:28) How will we define whether this product is successful? And often we have very, very smart people who will define what the product strategy needs to be. And oftentimes, my job is to just help them think about that and get out of their way. But I think what's important is to define—is to sit down and say, well, then how will we measure whether this is successful? When will we understand that we've actually done this well?

(Ashish Shastry at 00:36:49) So thinking about adoption, thinking about the metrics and the KPIs that define success is, I think, a very important part of what we're doing and what we're always trying to solve for. And I say solve for because I think that's where you can then not get rooted in business strategy and make mistakes. So defining that in a scalable, reliable way is also a very important part of what we do.

(Joel Beasley at 00:37:13) So you mentioned that just being able to hire fast enough is a challenge for you, which is an awesome challenge to have. So where are you guys—or do you hire globally, and what kind of people are you looking for?

(Ashish Shastry at 00:37:29) We do hire globally. So we have satellite office in Europe and a small function in Latin America. But, you know, the US is our headquarters, and, actually, the vast—from a just numbers perspective, the vast majority of our staff are in India. So, yes, first and foremost, we are looking to hire globally, and it's really run the full gamut. It's people from everything from the program management and program ownership perspective, product managers, analysts, and then, of course, engineers.

(Ashish Shastry at 00:38:02) Everyone from, you know, people that may be coming out of college all the way to engineering leads and managers as well. So it's really across the board. We have interest in hiring in all those areas.

(Joel Beasley at 00:38:16) Man, early in the interview when you said something like, this is like the secret industry that nobody knows about that's so huge. I mean, I didn't quite realize the scale that you're working at, but I think I just looked up on your LinkedIn. It says you have, like, over a thousand employees. So that's—

(Ashish Shastry at 00:38:36) That's right. Yeah.

(Joel Beasley at 00:38:37) Really crazy. Just—

(Ashish Shastry at 00:38:39) Yeah. It is. Yeah. It is. It is. And, you know, we would easily—if you said we have 200 more that could start tomorrow, we'd take more.

(Joel Beasley at 00:38:50) Wow. All right. Yeah. You heard the man. Apply.

(Joel Beasley at 00:38:57) All right. So I got one last question for you. What's been like the most impactful career advice that you've received from like a mentor during your time?

(Ashish Shastry at 00:39:11) That's a good question. I don't know how impact—well, it was actually quite impactful. I'll tell you, one thing my dad actually told me when—you know, so I was actually working at a big consulting firm for about a few minutes before I actually joined Odessa. And when I was about to leave and join Odessa and really start, I had noticed that my dad hadn't really said anything.

(Ashish Shastry at 00:39:46) You know? He wasn't like, hey, you should absolutely do it, or, hey, that's a crazy thing to do. You know? And so I finally called him, and I said, you know, Dad, I'm going to do this pretty crazy thing. You know? Do you have any advice for me? And he said, yeah. And he thought about it for a few minutes, and then he said, you know, you're going to start a company.

(Ashish Shastry at 00:40:07) You'll probably really struggle with money and just making sure that you can make ends meet. He said, anytime you think about—anytime you worry about not making ends meet, don't think about cutting costs. Think about growing revenue, which was simple, but I think it struck me. During those dark times where we thought we didn't have enough cash, we'd run out, it was a good way to think.

(Ashish Shastry at 00:40:32) I think it kept us pushing forward, and there were many times in my time at Odessa where I thought about that. So probably good advice.

(Joel Beasley at 00:40:43) I mean, dude, I think that sounds super powerful. I mean, whenever you're in a scenario where you're just thinking about cutting costs, you're not doing anything for the business.

(Ashish Shastry at 00:40:52) That's right.

(Joel Beasley at 00:40:53) Yeah. Awesome, man. Well, before we wrap up, is there anything that we didn't get to touch on today that we want to make sure we say before we wrap up?

(Ashish Shastry at 00:41:03) Oh, just, you know, I think there's just so much exciting happening in just all areas of technology today. I mean, I certainly don't need to tell you that. And just that we are very excited about what we're doing. We're helping some of the largest institutions in the world kind of enable their digital transformation journey. And so it's exciting.

(Ashish Shastry at 00:41:26) I mean, we've been at this for a long time. I've been at this for twenty-three years, but scarcely been more excited about what's going to come. So, I think maybe if nothing else, that's what I wanted to put out there.

(Joel Beasley at 00:41:38) That's awesome, man. Yeah. The future is bright and full of innovation.

(Ashish Shastry at 00:41:43) That is right. Absolutely.

(Intro/Outro Narrator at 00:41:48) 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.