S5 E11 | The Power of ICs, Leadership & Collaborative Growth with Jyotiswarup, CTO, Angel One

Speaker A: Foreign. Welcome back to the Tech Factor podcast by Purple Quarter. Today in the room, we have Jyoti. Jyoti, thank you so much for doing this on a weekday at your office. Thanks for inviting us over.

Speaker B: Nice to meet you, Rupa. Uh, happy, uh, to have this conversation.

Speaker A: Awesome. So, Jyoti, uh, let's begin with something interesting that we found on LinkedIn. Right? So you've put this up, right up on LinkedIn, saying that you dream it, I build it. Now, let's begin with that. So what aspiration that you had or inspired you to put that up on LinkedIn?

Speaker B: So what I figured out, um, midway m my career is I like building things and given a problem statement, uh, especially if it appears very hard, then it excites me even more, and it's a key driver for me to get things done. While saying that I generally, in terms of business ideas, when I started out, uh, middle of my career that time, I was trying out my own ideas.

Speaker A: Okay.

Speaker B: And what I figured out is I generally may not have the best implementable ideas. Business ideas.

Speaker A: Okay.

Speaker B: So, uh, then I just, uh, one day I just said, okay, I need someone to dream something, and then I'll build it. Right. I'm not a big dreamer, but I'm a good builder. So that's where I head up that line.

Speaker A: Okay. That's a lot of honesty out there, Jyoti. So just for the audience to know who Jyoti is, I'm sure most of them already do, but I'd like to introduce you formally. So Jyoti's, uh, done his be computer science and then his master's in computer science and started off on with R D side. And you moved to a couple of companies. I just picked the last three names because. And of course, one of my personal favorites, devfactory, you were with them, then you were with goibo, then you moved on to Walmart, From Walmart to Angel. Right. So that's been your journey. I see that you've been part of organizations as an individual contributor, and then you've now you're dawning the hat of a cto. Yeah. So tell us a little bit about, you know, your journey so far.

Speaker B: Sure. So I've been a techie at, uh, heart. Right. And when I started off, I wanted to do core. Core R D tech work. Right. So. And deep problems always interested me. Um, and I played different hat at different places. So even before I was an IC, the first startup I did in, uh, 2009, I actually led the whole tech team as well.

Speaker A: Okay.

Speaker B: Right. And then we did an exit after that. What I figured out it. I got tired of the admin stuff and said I want to focus on pure problem solving and pure ics. Right. So that's where I kind of um, according to the IC role and um, you know, and I generally uh. You know, one of the other things I realized is I'm also able to articulate a problem to mhm. A larger audience pretty well.

Speaker A: Okay.

Speaker B: Even as an ic. Right. And I think that is a force multiplier that you need. Right. Otherwise if you are just coding, uh, I mean your impact kind of remains uh, uh, curbed.

Speaker A: Right.

Speaker B: So, so that always was there. Right. And honestly if you look at it, I mean obviously there's a flavor of people management that gets in with the cto, but the code job is still the same. Right. Having a vision, um, uh, and communicating the vision to the team, you know, having um, enabling them um, uh, to do things. Becoming a force multiplier rather than uh, someone who, who is uh, you know, who gets into detail too many of their details in their lives. Right, sure. Uh, I think there's a lot of similarities in both the roles I would say.

Speaker A: Right. And if I were to actually take a cue from what you said. Right. You dream it, I'll build it. And also what you've just said that I'm able to articulate from a business perspective, a tech to a business. Is that the reason why you became like one of the investors, an angel? Avid angel investor I must say, and also advisor for a lot of firms.

Speaker B: Yeah, absolutely. I found that it was uh, you know, many of my friends started out and angel investing started out as, as helping out friends. Right. Bangalore is a very small tech space as you know. So it started out and I found that people struggled with few core things. Right. One is what is the actual product mix that they want to offer as an mvp? Because when you're just starting out bootstrapped fresh, there's a whole bunch of things you can do and only 5% of that will actually influence customer choice. Rest 95% is just uh, is just there for um, reasons of possibly completeness and add ons. But only the 5 um percent are the core things that customers care about. So how do you focus on that? How do you identify them in the first place, that was a problem for many founders. Uh, secondly, how do you keep things simple? How do you find the essence of the problem to be solved? Um, what trade offs do you do? For example, one of the uh, startups I advised in uh, E commerce seller space they wanted to create a lot of dashboards for sellers. So if you are let's say selling uh, mobile phones on Flipkart or Amazon, they wanted to create a dashboard on how things are doing in lot of geos etc etc and their stuff which they started out was very complicated. So one question I asked them is what level of freshness do you need for a seller? Do you need the seller to instantly see that RIPUR is picking up versus uh, uh, Bombay? Or do you want, does the seller actually only want to look at it let's say end of the day or maybe twice in a day with some clear insights rather than a bunch of 90 reports. And that forces thought and that simplifies things that actually gets you to the core problem solving first without wasting time on lot of other stuff which you can always build later on. I think that's the core uh, value that I bring uh to startups. Um, I would say.

Speaker A: Oh wow. And how many have you invested in? You don't want to talk about that?

Speaker B: No, there are about three or four active ones and I don't believe in just put money and forget. Right. I mean because I mean it doesn't uh, at least doesn't excite me for, for that. So I have checkpoints and I respect founder uh boundaries. It's their baby, it's their story. So I balance uh, in hands off, total hands off approach and working with them uh, with gentle nudges.

Speaker A: Right. Now I love the part that you said, right. 5% is all what the customers care. Now that's when you're starting a startup, when the idea is mushrooming. Now let's take a larger setup that you worked with, the one that had scale like a Walmart, right. So you have two pieces of it from a technology perspective, from a business perspective and a customer angle. How did you, you know you were of course you were a distinguished uh architect there. A lot of people in India don't know that, you know senior distinguished architects like a pricey position to have. But I'd like to ask you how did you maneuver that at Walmart?

Speaker B: Yeah, I think see uh, the, see in an E commerce space like Walmart, right you have lot of things to take care of. Right. One is uh first of all customer journey, customer satisfaction, traffic shaping and people search for blue uh, shirt are they landing on you versus your competition? So that is a key important thing.

Speaker A: True.

Speaker B: Uh, right, um, tech systems uptime is a very important thing. Compliance is a big thing. Right. So and uh, the Key to success is uh, business, product, tech, working together to solve the problems. Right. The minute it is a waterfall that business ideates something, then it goes to product, then it goes to tech. I think that is a recipe for failure because you abstract out details, you assume things and it's just slow. Right. You spend one month, one month, three months. Probably the problem you're trying to attempt has already gone.

Speaker A: Sure.

Speaker B: So one thing we did at Walmart and I actually was, um, one of the initial proponents of the ideas is we made something called four in a box. So you got business, product, tech and ops all together solving the problems. Right.

Speaker A: Like a pod.

Speaker B: Like a pod. And few key things. One is having a common currency for prioritization. Right. So let's say you have four things to do. One is build a new future. One is cut costs for whatever reason, uh, operational cost. One is a tech rewrite. Someone wants to rewrite the feature. Right. Generally you want people to talk in terms of the same currency.

Speaker A: Interesting.

Speaker B: So example, right. One thing we did is, and different companies have different things is one, uh, thing we said is if you save one rupee, it's equivalent to you saying you will get two rupees from a new future. Right. So, so that's how we prioritize tech ruggedization. If it's a core journey like a search or um, um, fulfillment, etc, it's worth 100 rupees.

Speaker A: Right? Right.

Speaker B: So then decisions, uh, prioritization and decision making becomes easy.

Speaker A: Sure.

Speaker B: So, so it's hard to define this, but once you get it defined you move fast.

Speaker A: Sure.

Speaker B: Right, sure. The other thing is implement metrics. Many people are very wishy washy about metrics, right. They don't, they say customer happiness, which is a very fluid and you know, meaningless metric. Right. I mean it's very difficult to measure. And then business will say I want customers to be happy. And you know, it's. Then the question needs to be asked is what is the uh, lead metrics to happiness? What is something that can be measured? Right. M. You can measure very easily someone clicking a link. It's very easy to measure, right. As a, as a techie, as a tech system. Right. Very difficult to measure happiness or even session times. Right. Uh, which is slightly less weird than customer happiness. But some things are difficult to measure. The more you focus on measurable metrics, um, which you implement in a dashboard and all four of the uh, folks are looking at them together when deciding things. It makes things smoother.

Speaker A: Interesting. But I do recall that Walmart did have a customer Happiness index.

Speaker B: Yes.

Speaker A: Am I right?

Speaker B: Yeah. It was a big company, you know like I tried or so. So I used to push back on such things. Right. And my product used to be, you know I had business stream across the globe. So I had like a Europe, uh, business team, South America, US and all used to come to me with different, different requirements and I was the focal point.

Speaker A: Sure.

Speaker B: Because I kind of figured out how to you know, me, my team rather, we figured out how to get stuff done for various GEOs and it was very difficult. Right. I mean if you are a Mexico uh, CEO you would say this is like life or death for me. Right. Where UK guy will say this is life and death. And sometimes they have orthogonal requirements.

Speaker A: Correct, Correct.

Speaker B: Right. What you want is exactly what the other guy doesn't want.

Speaker A: Correct.

Speaker B: Right. So, so we had to develop this framework very quickly get buy in from all people. So some of the things is what we implemented don't come with wishy washy metrics. Um, implement the metrics first. Before you say that you want to improve something first measure it crisply, correctly in a dashboard. So that helped us prioritize.

Speaker A: So let's say there are a few e commerce, um, initial startup, uh, entrepreneurs who are watching the show and they want to measure what will excite a customer. Can you think of three parameters that they should look at which could be meaningful in terms of measurable.

Speaker B: Yeah. So I mean let's look at the funnel. Right. Someone has to come to your app first. M. So that's your traffic shaping thing. How well is your app doing on SEO or the App Store? When someone is using Apple search and finding shirts. Uh, and that generally can be. There's a tech involved there and it's also a function of how much you are bidding, uh, for keywords, etc. But once the person lands then the funnel is totally in your hand. So conversion rates is a key funnel. Out of the 100 people that land on your landing page, how many people bounce away? How many people go back without even clicking deeper? If there's a search on your um, search on your app. Uh, when people type something, do they click on anything or not? So it's a null search.

Speaker A: Right?

Speaker B: Right. Uh, then you can go deeper into it. Okay. This null search is a clear bad sign that something is not working. A smaller problem would be click depth. You m search something and people are clicking at the 10th item or they're scrolling to the page two before. Right. That's a problem because if most people are searching for page two, maybe the stuff needs to be on page one, right?

Speaker A: Yeah.

Speaker B: So conversion funnels start from there. And lastly if you look at the typical E commerce, you have discovery, which is search, then you have a detail page and then you have the checkout. Ah. And the payment process. Other key metric conversion funnel is um, customer nps. How happy people are with the journey. And that will help you discover more problems. So one problem for us was Price Fidelity. M In search you see something in detail, you see something else. When you go out to pay, probably some GST or something else is added and people are frustrated. So 100 rupees, I'm paying so much more. So much more. M. So, so that comes out as a metrics and once you know the problem you can solve it.

Speaker A: Right.

Speaker B: So I would say focus on the funnel first. Right. Understand your drop off points, how customers are doing. Right. And yeah, yeah, this is beautiful.

Speaker A: Yeah, very advisory. Thank you so much for that. Uh, so let's actually go into what you're doing right now, Angel 1. And it's along with scale comes one more box, regulatory. So from a tech and a business angle, how have you gone about with angel one? How has the journey been for you?

Speaker B: Um, yeah, so let me start with the mechanics, right? I think uh, angel one of fintech is, I consider it another version of E Commerce. Right, whatever it is.

Speaker A: Okay.

Speaker B: Yeah. It's just that the inventory is slightly more complicated because shirts, you know, if you search for a red shirt, a red shirt will always be there.

Speaker A: Correct.

Speaker B: But let's say you want to buy reliance at uh, 1800, it's not always going to be there, right. The price fluctuates, so that's an added complication. M. Right. Um, so, so the, let's talk about the mechanics of broking. Right. So finally there's an exchange, right, where there are two cues, buyers and sellers. Right? If, if, uh, the, if you're selling something, if you are selling something for the least you are in the front of the queue. So it's sorted, uh, in ascending way. And whether you're buying something, if you are willing to pay more for it, you go right up to the front of the queue for a specific asset or instrument. So it's sorted, descending and then matching happens on the exchange. Now what people want to do is people want to get into the queue, they want to first understand what the queue like, how many buyers, sellers, what's the price like and they want to get into the queue first. So for us as an app, right, we have two basic, two or three Basic functions. One is we want to pipe the data from the exchange onto the millions of apps connected so you get a clear view of prices.

Speaker A: It's seamless as well, right?

Speaker B: Yes. It's quick. Right. It's not latent. And if you see 100 rupees here, it should not be 105 otherwise you're going to make a mistake. So that is a problem to solve. M Secondly, once you decide to place an order, we need to ship your order to the exchange as fast as possible. So this is unlike E commerce where you know, generally in a traditional retail E Commerce, once you say check out the card, it's all an asynchronous flow and you have some more time to uh, fulfill it. Here you need to be in the queue as fast as possible. So that, so that is the main uh, problems we try to solve.

Speaker A: So uh, agility and latency.

Speaker B: Yeah, yeah, Latency. Minimizing latencies and doing it at scale. Right. So if you look at our traffic peaks, it's like Swiggy, but am PM reverse.

Speaker A: Right.

Speaker B: So 9:15 market start. Before that there is very little traffic on the, I mean modest traffic. And then there's a steep ramp. M. And we have to handle the steep ramp at 9:15. When people have thought about what they want to do. Yeah. Right. And you got so many like, you got like millions of websockets from via which we ship prices. So you need to make sure things are perfect day in, day out. Right. Uh, so that's. Those are uh, challenges.

Speaker A: Right. So if I were to ask you from a perspective of, you know, while I like the uh, case study that you were talking about, that it has to go figure out what is the actual current price. So while you began the journey, were there times when things didn't go as per. What were the challenges that you faced with?

Speaker B: Yeah, I mean um, so, uh, incidentally, the day I joined, uh, we were just post ipo. Uh, scale was growing but still modest. But we were down for the whole day.

Speaker A: Down for the whole day.

Speaker B: Yes. So you know, even before my induction and I was wanted to meet people, I just, you know, I happened to be on an email chain where people are saying there's an issue and there's a call going on. This is Kobe time. So everyone is, you know, working from home remote. So I joined the call and one thing which, which, which, which was um, you know, it was uh, something which I found, uh, not great was people were not getting to what was the actual problem.

Speaker A: Okay.

Speaker B: Right. I think a common Thing was who's responsible for this? And stuff like that was going on this. So you know, so those. It took a while to get both people process and tech. Right. You need to move all three. Right. You need to move tech which is slightly easier. Right. You can rewrite systems changing people. Like you have ops. Let's. You have an ops person who's been spent 20 years with a setup. M. There's a way the person is tuned to operate with the setup.

Speaker A: Correct.

Speaker B: Right. Now if I give him a dashboard and say, you know, hey, don't call me. This is a dashboard. Everything happens on its own. You know, it's a, it's a. There's a lot going behind in the person's uh, mind.

Speaker A: Correct.

Speaker B: Right. Will this tech take over me? You know, will my jobs will still be relevant having to manage both and the process part as well. Right. Telling business that, you know, part of that. I told business I need a three month moratorium on new features. I want to make sure things are uh, you know, things still the lights are on first.

Speaker A: Sure, sure.

Speaker B: So yeah, so that was uh, something interesting.

Speaker A: Right. So generally, um, I'm sure challenges crop up everywhere.

Speaker B: Right.

Speaker A: Whether it is uh, trading or it is E commerce or the other places that you work with. So what are the you know, top three things you do generally to when you're going through a challenge or an opportunity. Right.

Speaker B: I think first thing is avoid um, premature optimization or platformization. So I think most techies, and I am a fault to that as well, we map problems to solutions we know.

Speaker A: Okay, can we go a little deeper on that?

Speaker B: Yeah. So generally for example you say you want uh, you know there's a transactional database and you want a read only copy and the read side is very heavy. Someone tells you the read scale is going to be pretty big compared to the writes. This is a common use case.

Speaker A: Right.

Speaker B: And Google uh, and they all have patterns like this called cqrs. So you write somewhere and it's actually Amazon has made a um, perfected some of this stuff. Right. So, and so it is a tech but it comes with a lot of its own challenges. If you have like a cluster of servers where one is taking the right. And you have multiple people taking the reads. Right. You can do that and it serves a purpose. But then there are a lot of gotchas that you need to solve. Right. For example, some readers might be out of sync. Uh then you need to have. If the writer goes down, you need a leader re election between the rest of the notes. Uh you know, what do you do with stale reads? So there are a lot of complication, complicated scenarios you need to handle.

Speaker A: Sure.

Speaker B: But what you may not realize is you're not Google. You don't have that scale. Right. And many times a single database, by having a slightly, um, different index, does solve lot of your problems. M. Right. So instead of just seeing what you read in a blog and just implementing that on day zero, you should start by building the most simplest thing possible and actually see where it is failing in your own context.

Speaker A: So you're saying apply your mind rather than.

Speaker B: Right. Start simple.

Speaker A: Right.

Speaker B: Ah. When I ask this, when interviewing people, and most people, they start with distributed system. I will have database and I will have, uh, you know, caches here and Kafka here and all that. I said no, solve it as if you're solving, you know, solve it in a single machine first. Right. Write code for it, pseudo code for it, whatever. Right. To solve it within a single, uh, instance. Right. Then you know what to scale. If you start building blocks and start, um, distributing things from day zero without you understanding the problem or you understanding the scale or the context, you are bound to over complicate. And once you overcomplicate, you will spend a lot of time solving problems which you don't need to solve. And that is a travesty.

Speaker A: Sure.

Speaker B: In our business.

Speaker A: Sure. So even when you had. When problems are thrown at your face, you start with finding, figuring out what the problem is. If I'm correct, then you find a simple solution which will address the problem.

Speaker B: Correct. First is measurement. What is the actual problem you're trying to see? Right. And sometimes the easiest solution go live. So someone tells me, you know, figure out, uh, use data science and figure out this and that. Most of the time you don't need data science.

Speaker A: Is it?

Speaker B: Yeah.

Speaker A: Yeah. You're sure you're saying this on the platform?

Speaker B: Yeah. Most of the time you don't need data science. Uh, you know, actually you should start building a solution without too much complications. One basic thing. Right. And figure out what it is not solving. M. Right. Rather than bringing a, uh, uh, a plethora of tooling which you have learned. Right. And trying to see whether it fits or not. Because then it's very difficult to pivot.

Speaker A: M. True. True. Because you've already created a monster.

Speaker B: Yeah. You created a monster. And when, let's say you are my CEO and say, no, I want slightly different. Right. Then it takes a lot of time for me to pivot.

Speaker A: Yeah.

Speaker B: Right. And then you are frustrated. I am Frustrated. Right, you're frustrated. Why is Jyoti moving slow? I am frustrated by Rupa changing your mind. The reality is both of us will do that. You will, you will figure out and explore what makes sense for the business to do. Right. And my job is actually to, to move with you in speed, in log step, as, as iterate. Right. The minute I have, you know, like, lot of lot uh, of this, like bells and whistles, it slows us down.

Speaker A: But on the contrary, um, Jyoti, what you're saying I agree with. But on the contrary, if I were to look at it now, let's think of karma. Um, companies which started off small, didn't expect the kind of scale. But if I'm just going to solve for the problem I have at hand and not look at the bigger cursory effect, then I'll have to re architecture the entire platform.

Speaker B: Right? Yes.

Speaker A: How does that work in your side of the world?

Speaker B: Yeah. And it's, it's. It's not something which is a bad thing.

Speaker A: Okay, it's not a bad thing.

Speaker B: It's not a bad thing. Right.

Speaker A: Okay.

Speaker B: I mean, tell us more.

Speaker A: Why is it not a bad thing?

Speaker B: First thing is the fact that you need to re. Architect means that your business is successful. Right. I mean, so that's a unique way

Speaker A: of looking at it.

Speaker B: Okay, so that's huh, that's really. Right. I mean, because you're getting more users.

Speaker A: Sure.

Speaker B: Okay. So congrats. Right. 95% of startups don't end up there. So you are already at top of the funnel. And then once you actually solve, and I've done this at bunch of places, Go, Ibbo, angel, etc. You don't need to solve everything coming to an E commerce funnel, right. You have like search detail and payouts, right. Payment gateways. Generally the scale at the payment thing is not very high. M so in go away. Also, if I remember right, we didn't change that it was built in um, Python, Django, which is a pretty unique stack. Right. And we never changed it. We built Golang microservices. We built a lot of other things for the rest to scale like search. We really re engineered the E commerce search, right. With the detail paging, how we added offers. All that was re architected but booking and the final payout, it was not broken. The scale that it was being thrown at that uh, system it was able to handle. So you can starve out what is broken and fix it uh, separately. You don't need to change the entire thing.

Speaker A: Got it.

Speaker B: Similarly, data science coming to saying, when you have heuristics and the heuristics start becoming very, very complicated, that's a great time to say, okay, I want to invest in data science now. So, for example, if you're programming, if you are spending on programmatic, uh, ads and you have lot of if else conditions, if the person is in, uh, you know, west of India and if you know, he or she is above 45 and something, something show this keyword, then you know it's better to get to data science. But you don't need data science on day one.

Speaker A: Correct. True. True. Only at a certain point.

Speaker B: Yeah.

Speaker A: No, I'm with you. So from a perspective of angel and because you're dealing with so many customers, can you talk about even customer data? How have you go about making sure, you know, there is privacy maintained and stuff?

Speaker B: Yeah. So if you look at data and how there are three main patterns for data. Right. First is, uh, I ask what is Rupa's date of birth? M. Very specific question. Toughest one. The second one is like, not answering. Yeah, I'll get to that. The second one is, is this Rupa where I don't need to store Rupa. You know, I can hash Rupa's, um, name, email and all, and I can do a equality check. Sure. I never store Rupa. This is how you typically, how we typically handle like, um, PIN codes and stuff like that. We never store your PIN codes.

Speaker A: Okay.

Speaker B: We store the hashes. Right. Um, so when you put in your PIN code, it's hashed and then we figure out it's an auto fill. Right.

Speaker A: Then it brings up my.

Speaker B: Yeah, I mean, in the sense. We never store it.

Speaker A: You never store it.

Speaker B: Okay. Right. Uh, because we transform it and then we compare what is transformed.

Speaker A: Okay. Right.

Speaker B: In the first case, I can't transform it because you actually want your date of birth. So I can't put XYZ there. I have to give whatever the date of birth is.

Speaker A: Sure.

Speaker B: And the third is the most complicated search. When you have something like an inverted index and you're searching for customers and you say ro, then I need Rupa, so I need to store data there. So these are three query patterns. Essentially, you need to handle things, uh, um, for each query pattern slightly differently. So we have two main things. One is, as far as possible, we try not to store the data. Right. As I said, mpins, uh, Aadhar, you know, we don't store the full Aadhaar. We store the masked Aadhaar and stuff like that.

Speaker A: The Kyc you have to still take those details.

Speaker B: Uh, so there. Yeah, so some. So many say kyc. Right. So we need some documents for government. Uh, um, uh, like for example, when you push data to the depositories and all. So that is just. We are handling.

Speaker A: It's a flow.

Speaker B: It's a flow.

Speaker A: Okay, Right.

Speaker B: M. Many times when we need to store it, we tokenize it. Right. So, uh, for example, everywhere else, Rupa's date of birth is xyz.

Speaker A: Got it. Understood.

Speaker B: Right. And there's only one vault where we actually do xyz. So we actually need to secure that vault.

Speaker A: Very interesting.

Speaker B: Right. Because everywhere else in the logs. You know, many developers put things in logs. This is a common problem. They log requests and responses and stuff like that. Or Rupa asked for date of birth and I replied, you know, now because if, if that person replies xyz, nobody. If the logs are compromised, nobody goes to know your actual PI. It's only the vault that we need to secure. So tokenization and encryption is something that we do. So we re encrypt stuff. We have continuous re encryption. So whatever the vault is, the keys that we use, we continuously re encrypt with newer and newer.

Speaker A: This is very similar to how crypto is done. Tokenization and stuff. Yeah, very interesting. M. So that's how my data is secure.

Speaker B: Yes, it is.

Speaker A: So you're telling a lot more people to jump onto your platform.

Speaker B: Absolutely.

Speaker A: Interesting. So let's go into what's been the buzzword of, uh, um, the hour, which is Genai, of course, we'd heard of AI. Now where people are talking about gen AI. What are the few advancements you're planning at, uh, Angel?

Speaker B: So I'll give two examples where I have a small team called Labs, where we.

Speaker A: Okay, define small.

Speaker B: So small is like 10 people. 10, you know, one designer. Okay, 11.

Speaker A: Sure.

Speaker B: Right. And we try to figure out how do we move the needle. You m know, what do we look five years and how things will change. So I have two. Two problems related to this we are trying to just scope out. Right? So the first one, you know, like if you look at generative AI, it's all about token prediction. So you have a sentence, right? Saying this model was dash. And then you start predicting what is the next token. M. Uh, and it has things like embeddings. Uh, model has a specific representation in a vector space, Right. And then, um, that is enriched by what's in and around. Okay, Right. This M model was right. And model could be a machine learning model. It could Be a fashion model. It could be a lot of different. And what is before the words. The generally, um, has meaning. Um, adds meaning to the last word. Model.

Speaker A: Okay.

Speaker B: That's what is before adds meaning to the last word.

Speaker A: Understood.

Speaker B: Right. This is the attention part, which is new in the. Jenny, I think the words behind you kind of add context to you. Um, you know, in a most, um, simplest way of explaining. Right now this is language, uh, generation. Right. Uh, if you look at financial things like your quarterly results or prices or agricultural production, everything is a time series. Right. So something happened yesterday, day before yesterday. Right. And if you can reasonably predict. Right. If all these different time series how it's going to affect a sector or a company. Right, sure. So that is a very valuable information.

Speaker A: Wow. Now I can actually tie it to what angel will do with this. Right?

Speaker B: Yes. Right. So you can imagine. Right. So we can say.

Speaker A: So speculation, basically.

Speaker B: Correct. We, for example, we believe that ice cream companies will do a good job in the next quarter. Right. It's not speculation. It's an informed guess. Right. So why. Because let's say we, we have temperatures in Bangalore on a daily basis. Right. And we see temperatures going up. Going up. And the average of the temperatures is um, is more. Then we infer that when temperatures go up, people buy ice creams. And this is no heuristics. We, we look at news. You know, we look at news, we look at what comes together when it's hot and what brands. And because our set of brands is small companies are 700 companies on nifty. Uh, right. 700 important companies on Nifty and their businesses. Right. And so the target, you know, is small. So all these events happening. Bangalore is hot. That how also the 700 companies, what impact would it have? Right. At least a directional thing. We can say it's positive or negative. Right. Air conditioners, you can quickly figure out, right. Things are getting hot. Air conditioners, ice creams, dairy manufacturers, you know, people who make Coke are going to go up. Right. Someone who's sending you blankets probably is business is not going to be um, that. That great. Right. So you can predict directional things. Right. And then it gives you into sectoral rotation. Money flows from one sector to another. Right. And you know, like, um, even in our tech side, you know, um, blockchain was pretty big some time back.

Speaker A: Yeah, it was gen. Yeah.

Speaker B: So money keeps flowing. If you can see where the wave is, we can help people make informed decisions.

Speaker A: So let's also add a little bit of um, fluidity to our discussion. Right? Let's bring the session in. Yeah. So let's say that you know, with economic standards things go up and down. So in fact the purchasing power parity also may have. How is Genai going to contribute to that? I mean are you adding variables to the whole thing? Because what you just said was extremely fixed pattern, right?

Speaker B: Yes.

Speaker A: So what if there are variables to this?

Speaker B: Yeah. So this is the second part in which we are trying to do. And the second part is very simple financial assistance. M We have all had various level of financial advisors available to us. Right. For me it started as a relative ah. And he just told me sign this, this is your sip. And you know like I was like I was a kid, like a zombie. Yeah, you know how it is. Or someone comes to you like tells you do this. Yeah. You start doing that.

Speaker A: Right.

Speaker B: So it's. And even with the best of advisors, right, you ask yourself questions like how fiduciary responsible is this firm?

Speaker A: Correct.

Speaker B: Right. If I take let's say 10 lakhs from you, you say no, how much is he going to be keeping? Right. How much is his expense ratio? Will he optimize? Will I tell you Rupa, uh, I've taken 10 lakhs for you but things are not going well or I don't know what to do.

Speaker A: Correct.

Speaker B: It's a very good thing to say, here's your money back. You would think that. And most people don't do that. So we are looking at a ah, agent which uh, knows the domain, the financial domain knows about you. You know, rule about rupa for example is Rupa, uh, risk covers, right. Is RUPA loss hours, very different things. Right? Do you hate losing money? M Right. So we can optimize for you or are you, do you do not want to take risks, right. So so understanding you is is first step in solving for you. I can throw in generic stuff, right?

Speaker A: Just so personalization. You talk.

Speaker B: Yeah, exactly. It's a very abused word. But I didn't want to say sorry. No, no. But you know, so solving for you is very important. Understanding you is very important in solving for you. So there's very different problems. The third one is this ethical and fiduciary responsibility. M Luckily there's set of tests which um, which, which universities are working on to test out all these factors. So you know, and using a foundational model like GPT and all, we can add a thin layer on top and then we can run this regression test. So if I run, if I add some little bit of more context to this model and start answering questions as a financial advisor on all these three attributes. How am I doing? Am m I optimizing for brokerage, for example, when I am telling you stuff, or am I optimizing for you? Do I understand your choices very well or not?

Speaker A: Sure.

Speaker B: So, so that's the second part. I think that is going to be, you know, if someone, if you're able to, you know, it's a hard problem, but whoever handles it, I think that's it. Because I think um, that's the most important problem for a person with macroeconomics being what they are and you know, things going up and down. People want to secure their futures.

Speaker A: Absolutely.

Speaker B: And they cannot take decisions on their own. The choices, the amount of mutual funds that they are there, how different each is from another. They're complicated choices. Right. And you need help.

Speaker A: Right. Can I add one more attribute? I know I didn't. It's called an attribute.

Speaker B: Right.

Speaker A: Firstly, it's not a variable, rather. So what, what about time value for money? Are you guys thinking of that as well with gen AI?

Speaker B: Um, yeah. So I mean, uh, we have very good mathematic models. Um, so there's no gen in terms of black Scholes and all for time value. So if you're putting in 10 rupees and you're expecting 20 rupees, how much is the actual money that you'll earn considering your, uh, you know, um, considering the time value of money? Right. So they are. There are fixed equations in that space. Okay, so right now we are not exploring that right now we're just solving for these three attributes. Again, it's a personal thing. You know, how many, how much work ten people can do?

Speaker A: I don't know.

Speaker B: To put in more.

Speaker A: So I hear you're hiring for this team.

Speaker B: Yes, I am.

Speaker A: Okay, so what are the kind of people that you'd be interested who can. Actually, we'll leave your handle so they can write to you.

Speaker B: Yeah, absolutely. So we want problem solvers and problem solvers who are uh, literally full stack right from design. So I'm, you know, I love engineers who debate with designers saying this button should be blue for reasons. Whatever they are, you know, finally you disagree and commit. But they have skin in the game.

Speaker A: Sure.

Speaker B: They understand the problem, right. From design to M either back end, front end, both. And data science. I, um, am, you know, I have enough PhD data scientists, you know. But even if they are PhD, I would prefer a PhD who's an engineer. Someone who writes code, you know, who can work with models and who can Actually take things to prod. End to end, end to end. Right. I think those are the kind of people, um, we want because we are not solving academic, uh, questions here, to be very honest. Right. These are real, real life, Real life problems. They're difficult problems, good problems, but they're not academic, uh, in major. So.

Speaker A: So do you have timelines for your releases? I mean, if you're looking at Genai, I mean, you spoke about.

Speaker B: So some of these problems we want to put out only after we are very sure. Because our regulatory constructs are very severe.

Speaker A: Correct.

Speaker B: Right. So we can't just put out things like this, you know, so it's, uh, a. You know, I think, uh, Pramod Verma, uh, said it in GFF. Bangalore is in 2035, you know, Mumbai is in 2025 and Delhi is in 2015. So we have to work with all our stakeholders to make sure they're comfortable, they understand what's happening. What are the guardrails, you know, uh, because we can, with some things like this, we can move a lot of the needle very fast. So we're slow here. So we experiment on close user groups and all. But going live, we will take our time on some of these things.

Speaker A: No, it's valid as well. Right. Because customers will also. It's also in terms of how each one uses the available data.

Speaker B: Yeah, right. And to prevent fraud and all the other things.

Speaker A: Correct. Makes sense. So, Jyoti, before we wrap up, I have, uh, one question to ask you. Because I've known you from a time that you've been in an IC and then you started handling a team. Now you tell me that you're handling a 500 member org. So, two set of questions.

Speaker B: Sure.

Speaker A: So what's your advice for people who want to be closer to tech problems, that is individual contributors, what should they actually look for? And the second question that I have is, if they want to transition like you did from this role to this role, what are the few things that they would compromise or, you know, they would have to see it in a different day of light.

Speaker B: These are great, great questions. Right. So I think as an ic, and there are two, uh, um, brands of ic. One is a principal engineer.

Speaker A: Correct.

Speaker B: Right. Someone who's deep, deep into, uh, um, a tech of the person's choice. So it could be like front end or backend or data science or whatever. If you really believe that's your, um, that's your place where you're going to maximize your, your talent, then it should go deep. Don't digress don't try to uh, don't try to kind of, you know uh, don't try to average yourself out by saying I will also learn front end coding. Right. Because you're not, you know, you are a backend person. Then stay, stick to, stick to it. Be really good at it. And there'll always be huge demand for people who can solve those type of problems. Right now there are other sets of brand of ICs right. Who are horizontal and they talk to businesses and then they map the problem into lower level constructs which can then be solved in a much easier way. So they are more business problem solvers rather than tech solvers. They understand tech obviously to create it. There's still code but their job more is translating business solution architect kind of correct. A solution architect is a, I know

Speaker A: it's a one end of the spectrum

Speaker B: but you know there are a lot of people who work with business product and scope down the features. Right. I think that is a segue to uh, I think uh, a top tech leadership role.

Speaker A: What do you call them?

Speaker B: So generally it's a difficult thing. So I call uh, these engineers the, the one who are heavily focused.

Speaker A: Correct. Experts like your experts.

Speaker B: They'll know in production what line of code is affecting that. Right. So they see incident and I have some folks who, I mean some guy who you know who inherited lot of very uh suboptimal code and ah, like stored procedures. Like I remember there's a file where fired five 50,000 lines of stored procedure and he's able to correlate, he was able to correlate rather something that happened in prod to this specific line of SQL code which is mind blowing. Mind blowing. So we have guys like, we have people like those uh, the other kind of people, we call it architects.

Speaker A: Right.

Speaker B: Because that's what they do. They talk to business product compliance and then they build like a uh D bus and mhm. This is how the system will look like frameworks. Yeah. Right. So. So that's how we are looking at it right now.

Speaker A: Sure, sure. And what about the second set of question that I asked if they want to transition from here to what you're doing today? Building large teams.

Speaker B: Uh, so I think as a building large team the first thing you need to figure out is how do you enable people. Right. So there's management and leadership. So as a manager if you are just um, if you are looking at people's um, you know it doesn't scale well compared to leadership. Right. And um, I think for ICs getting into a leadership role is much easier than getting into a managerial role. And there will be. And sometimes it is confusing. What is a leadership and what is managerial? Managerial means you are over indexed on let's say things like stakeholder management and um, uh, you know, uh, getting out metrics or story pointing or stuff like that where those kind of folks can get bored.

Speaker A: Right, right.

Speaker B: Leadership is whole different thing. Leadership is. It's. I think about people. You know, it's very wrong thing to say. Is exactly the way I think about systems. I want to build a massive castle of really good people. What are the building blocks? How do I make sure those castles work together? Those building blocks work together look beautiful as a castle.

Speaker A: Right.

Speaker B: How things don't fall into place, how it can work without me being in part of it. And I think that so, so that is uh, the way I look at it.

Speaker A: Very beautifully said. So when people want to shift gears from being ICs to becoming a leader, I'll redefine that. Um, what are the few things they have to compromise on? Because you've uh.

Speaker B: Yeah. I think first thing is don't solve the problem. Right. If you open your mouth first.

Speaker A: Right.

Speaker B: You set biases. Right. And then it becomes an eco chamber. Right. I say something, oh, we should use Kafka. Everyone says ah, yes, we should use Kafka.

Speaker A: Right.

Speaker B: So that's a very critical thing to avoid. So generally avoid giving opinions on technical solutions.

Speaker A: Sure.

Speaker B: Right. It's difficult. You need to hold yourself, hold yourself back. Right. And um, and especially when someone is doing something wrong, you need to figure out when to time intervention. M. Right. So that the person can learn. It doesn't, you know, they don't feel as if we are stepping on their toes.

Speaker A: Correct.

Speaker B: Yet you don't impact ah, timelines or production. Uh, Right. So that's, that's hard. You need, you know, it takes a little bit of practice and errors to get. Get it right. Right. So that's one. Secondly I think uh, the basic logistics of it, 500 people org in terms of budgets and stuff like that, that is something that you need to understand very well. Right. How do you budget something? How do you budget for hr? Non HR costs especially in a regulatory changing way.

Speaker A: Right.

Speaker B: That is, that is an art and a science that you learn.

Speaker A: Sure.

Speaker B: Um, I think the third is stakeholder management, which is something new. Right. When people rely on you and um, building those relationships like speaking tech to a business person and speaking business to a tech person. Right. So you wear both hats, complimentary hats, that's something that you do because people respect ICs. That's what everywhere that I see, right? People, you. An IC walks in the room, everybody nods the head and says, great, yes. Nobody respects a cto. They think I am either, you know, I am, I am either being lazy or I'm, uh, protecting teams or I have some other agendas, uh, and stuff like that. So nobody takes me on. You know, I have to solve, uh, a problem together with the stakeholders saying, this is why. And generally it's, you know, like when they say, why is this taking time? Or why can't we do this? It's a step by step thing. I just can't say, uh, you know, and in earlier lifetime, I would. I was able to say, just walk in the room and say, no, we won't do this. And people say, okay. He said, yeah. So you miss that? Um, you miss that.

Speaker A: Very interesting, Very interesting. It's actually a flip side to what people, uh, don't know and they don't watch out for.

Speaker B: Right.

Speaker A: So very beautifully said. Before we wrap up the show, would you like, like to have any few words, Would you like to share with the audience? Anything in specific?

Speaker B: No, I think, um, generally, I think on the career paths, right. I. I don't think there are any irreversible decisions. Right. You have one life and you want to make. You have to make sure that you explore all avenues before you kind of retire.

Speaker A: Right.

Speaker B: So don't be afraid. Don't get pigeon rolled yourself. Right. Try to see what you're good at. Try to explore. And this, this is a huge lifetime for young engineers. Right?

Speaker A: Absolutely.

Speaker B: So. So. So don't worry. And we live in very interesting times even now.

Speaker A: Correct?

Speaker B: Right. If you have creativity, you have talent, you, you, you are able to basically do anything that you dream of. M. So I think exciting times. Don't get bogged down. Don't get pigeonholed.

Speaker A: Very nice. Very nice. Thank you so much for coming on our show, Jyoti. It was really marvelous having this chat with you.

Speaker B: Thank you, thank you, thank you.