A (4:21)

I really like your approach in terms of bridging the gap. And I'm, you know, I talk to lots of people who are on both sides of the gap from, you know, the dreamers who want everything right now and think this is completely changing the way, you know, every aspect of a company runs, you know, and the people who are saying, you know, let's slow down and really, deeply understand what's going on here with the first camp Bala, one of the things that you hear about a lot is this notion of vibe coding and that the technical craft that's been historically done by developers and engineers just doesn't really matter anymore. And, you know, I've seen the obituary written for, you know, software development as a practice, you know, more and more frequently now. And, you know, I mean, I'll tell you my opinion, which is that I'm a little bit skeptical of that. But I'm curious from your perspective in the fray, in a world that bridges, you know, these Two sentiments. How are you finding it? What is it good for? What is it not good for? And what do you think is the, the outlook for this whole profession now?

B (5:27)

Very true. It's like a reality we are walking into every meeting now these days. It reminds me when Google came, some of the doctor's offices actually started putting a board which said my medical degree is better than your Google search. Right? Because at that point we go to Dr. And say, oh, I see these symptoms, I think it could be this, I think it could be that. And then doctors are like, okay, okay, hold on. Yes, you're right. But there's a bigger picture. I feel. Engineers are now going through that phase with wipe coding because wipe coding actually has democratized software development like anybody can come and do within like few proms, within few minutes, regardless of role and level. And it's good for prototyping. It's good to show something. Traditionally, if a product manager has something or a designer has something, they have to create an artifact that took a lot of time just to convey an idea. Right now that cycle can be reduced drastically to show a prototype quickly. However, when we want to talk about productionizing it, actually putting it out there where it can get shipped and stay afloat without getting sunk is that's the piece where we should be cautious and not really do so. Identifying areas where it's less risky, like if you have internal tools, if you have things that you can use to show something to others within to build great things like tools are okay to use wipe coding and stuff. If until we have a proper guardrail, right. We cannot just put it into production code because it's going to impact depends upon the industry. The repercussions could be huge. Talking about medical, talking about sensitive security stuff, it's really risky. So identifying like low risk areas, internal areas that are not too dangerous to put out, it's a very good place to practice also that's a good practice ground so you can take that art and go and do it in the real world. So that's why giving it to experts like people who have done the craft like you said, they can actually understand, okay, how can I use this to accelerate with proper guardrails, with proper systems and mechanisms so things doesn't go out of proportion and blow out

A (7:50)

if you work in it. Infotech Research Group is a name you need to know no matter what your needs are. Infotech has you covered. AI strategy, covered. Disaster recovery, covered. Vendor negotiation, covered. Infotech supports you with the best practice research and a team of analysts Standing by, ready to help you tackle your toughest challenges. Check it out at the link below. And don't forget to like and subscribe. I think you and I are basically of the same mind, that there are a lot of good uses for it. But you know, production, environment, code and systems at scale are probably not the first place to be to be using vibe coding, which makes complete sense. One of the kind of macro level questions that's coming up, and we're seeing it play out in labor market stats and in company press releases, is whether these new tools decrease our reliance on software developers and whether they, you know, create a world where we just need fewer software developers. You know, the idea being, well, if there's higher productivity then, you know, maybe we need few fewer people and they can do, you know, the same or they can do more. I'm curious on your perspective on that. Are you seeing the trends here and saying, oh great, you know, this is a world where, you know it's going to be a smaller team or is that, you know, in some way just fundamentally misguided?

B (9:18)

I would say it's still in the learning phase. So I know some people are on the edge taking more bolder decisions, but on the other side, I would say people are cautious because all the researchers that are coming out like the long running ones, right? Long running research. And when I say long running, I'm talking about a year long. That's the age we are in. And with large scale like Stanford has a study, MIT has a study, the productivity is coming somewhere around 10, 10 to 15%, maybe 20% max in some areas. Purely in engineering angle. Right. Not in other functions. So companies at this point, there are some who are like boldly making statements and like you said, every earning statement now comes with the AI. Without AI, there's no earning statement that gets completed. Quarterly earnings are always having some AI, especially tech companies are talking about, oh, 50% of my code is done, 70% of my code is done with AI. So then that begs the question, oh, then what are the other people doing? Or are you creating more than what's a consuming aspect? I think fortunately people are not using AI as a reason to cut the team size and still operating in a model where, okay, let's start creating more output, right? If I have 10 people team, just gonna have seven people to deliver the same versus oh, 10 people can deliver more than what they used to deliver before still in that camp. But I really am not confident that that is going to be the forever camp because there might a shift and say, oh, I'm just going to make a decision and then come back. We have seen this again and again where preemptively jumping to a decision and rolling back. So that is common and we have to be vigilant. And that's where leaders come in. Like being realistic about what you want to promise. What do you think is going to happen before calling a hunch. Because this is dealing with people and life and industry economy. There's like macro impacts for these.

A (11:20)

I agree with that and it's interesting to me and I find myself coming back to that number you quoted, which is kind of a 15 to 20% productivity gain. And one of the reasons I find that so interesting is first of all that the conversation is focused so much around productivity. And even the piece that sort of rubs me the wrong way is somebody who's worked with developers very closely before is as you said, like people talking about like 80% of their code is written by AI. And this notion that you can measure the value of software development by like how much code is written, just like, you know, for, you know, people like us who have been there, like, it's, it feels a little bit silly. And so I'm curious, from your perspective, what are the top traits that you think are important in a software developer? What's more important than ever? What should a great software developer be spending their time doing or thinking about if it's not just, you know, hands on keyboards for, you know, 40 or 80 hours a week?

B (12:25)

Yeah, yeah, totally. It's true. Like we are still in the industrial mindset, measuring output by throughputs. Okay, how many soaps did I make today? How many cars did I make today? That that becomes the count for software. Actually this has been a practice even before. Once upon a time we talked about a kloc, right? Kilo lines of code. That was actually a measure in some companies back in the days and they moved away when companies like Google and Facebook came into being. Like they really redefined those performance metrics. And now if you look at the software development life cycle, like coding is really not the constraint. Like if you look at the whole thing, nobody says, oh, it's going to take so much time to code. Like, nobody ever says no, it's always other activities. It's always about, oh, coordinating, checking, testing, validating, verifying and like aligning. Those are the things that are going to take time. That's why the gain is 10, 15% maybe. Yeah, I can now let my AI agent write a unit test which I would spend maybe Half a day to write or like a day to write. So that's where we are seeing the gains realistically. The other part is still real. To your question, what should a software engineer focus more on? Continuing. Continuing to have the curiosity is going to be the key. An engineer is defined by curiosity always, right? You have to be curious when something is working or not working. You have to be curious. We have had this time in the day where sometimes we write something and then it works magically and then you are a true engineer will not be convinced. I don't think it should be working. Maybe something is wrong. Let me try something. Right? Keep the curiosity because now more so than ever you are actually looking at a code that is written by a machine that is written by a piece of code. So being curious to understand and there are companies which are talking about debugging is dead. You can just regenerate. All we need is prompt. Yes, those are the companies selling LLMs. So they are going to say that more tokens, more money. So being curious and having a more critical mindset, as always, engineers are considered as the pessimist in the room ever. Like they are going to be, oh, this is not possible. That's a cautious pessimism that's needed. Keep that curiosity and then whatever your workflow is, apply that. Then you'll know if you're curious, you'll identify everything.

A (14:58)

It makes sense to me and I'm thinking as well about something you said earlier about being this bridge and being intentional with what you're building. How important is it to you bala

B (15:08)

that

A (15:10)

engineers and engineering teams are actually interfacing with the rest of the organization and understanding, you know, kind of the, the product, the customer and the broader business context is that is that a nice to have or a need to have? And is AI changing the where the value is in that role?

B (15:34)

It's a must have like since day one, right? Like it's back in the day when we had traditional waterfall. That's when okay, there is a customer facing team and then they come to the product team and they come to an architect and they come to high level design. Then it goes to an engineer who actually codes. There is too much of gap in between. Things were changing with Agile already. Customers are part of the equation. There are companies where even Scrum teams will have a customer coming to their demo, right? Hey, show what I'm building, get immediate feedback. That's more important and that is what actually changed the last 10 years. If you look at software evolution, especially after mobile advent of Mobile and apps, it really changed because end of the day, every engineer who has a phone and they look at their phone with so many apps and they in turn start thinking about, hmm, this app doesn't look right. Oh, maybe I wish I had this thing. We are all channeling our inner product manager just by using the apps that we use in our day to day. And that makes you a better engineer. With AI, it's even more important than before because now everyone is going to use AI in their work cycle. Right. From a customer to a designer, a data scientist to a UX researcher, every role you could think of and they're using AI in a way to help them and the context is being built. So this is why, again, putting customer all the way closer to engineer or engineers going all the way in front of customer will shorten the loop and make the context more rich and valuable. If we come to the world that is being promised where, oh, all you have to do is write prompt in that case, that context and customer interface is going to be the critical one. Like every engineer is going to be a full blown pm. The ratios are changing. So even more important than ever before.

A (17:27)

That's. That. That's exactly what's on my mind is that in this era where it's easier than ever to, you know, ship something.

B (17:36)

Yes.

A (17:37)

That you could be subject to this notion of almost like feature slop.

B (17:41)

Yeah.

A (17:41)

Right. You know, coming back again to what you said about intentionality. And so, you know, from my experience, one of the places this falls down is with requirements or having some sort of North Star where the people building the product or the features actually understand the value and, you know, what, what needs to be done and have that sort of guiding light. How do you, how do you approach requirements? How do you make sure that, you know, the, the team is picking the right thing to build, that they're actually building it in a way that's going to be most valuable.

B (18:17)

Yeah. It has always been data driven. Right. Like within any new modern tech stack, if you're building B2C mainly, it's highly data driven, like insights driven. You need to experiment what works, what doesn't work. Now more so than ever, you have that ability now you can reach audiences who you wouldn't have had the access to before. You can experiment with multiple variations, which was not possible back in the days. The systems that allows you to experiment now, it's much more versatile and very, very powerful. Same with requirements too. Before it's a single tunneled way. I would say, like Univision It's a pm Maybe you go close to a customer. As an engineer, you talked about requirement and when we talk about, okay, what are the various angles, what are we missing? The various angles depends on the number of people in the room. That's why we talk about building diverse teams. Right. To have different perspectives. But now with AI, I see there's a benefit. Like you can run multiple simulations, you can have them play devil's advocate and like kind of tear apart your hypothesis and then you come up with something stronger and better. It's like you have a thinking tool that you can apply in so many different ways. So the requirement phase and how quickly you can test a hypothesis, that cycle has shortened. So that's the fun part, like the learning. I can just do something and know what's happening right away. So that's in the instant gratification is coming, it's good. But also it's in a way takes away some fun. I would say sometimes you take, you build, you kind of lead up to it and then get it. So coming from old school, I miss that waiting game. But, but still it has opened new doors. So there are benefits to that. I'll take the benefits any day.

A (20:14)

It's really interesting. And again, it sounds like Lyft is sort of at the forefront as a number of, you know, kind of bigger tech companies are in that space. So can you just unpack a little bit what that, what that process looks like when you're using these tools and maybe even get a little bit into the tools you're using there on the requirement side to build these faster and play out some of the scenarios.

B (20:36)

Just

A (20:39)

paint me a picture.

B (20:40)

Yeah. I'll tell you a very, very recent funny story. We had a design review so designers would come and show their prototypes. Right? Meaning mockups. Okay. This is a concept. We want to solve this problem because it's a customer facing rider app that every one of us is a customer there inside that room. Because we all use this app to take our ride share. So we all know very, very in depth, we know what we want, what we don't want. We get into this room. Usually traditional design walkthroughs have been with figma. Right? I mean, I say traditional figma itself is not that old, but we have come to that age where everything is shortened. So people designers would come and put 20 different screens on Figma and they'll walk through. Some designers would go one step above and create a prototype where you can click and play through the dummy mockup. But most traditionally it's like just 20 screens, screen one, screen two, screen three. And then you get the full context. And yesterday, like how things are changing now is like. We went to a recent review where this designer actually built a prototype from their design using cursor and pretty much built it in a framework where you can just look at your simulator screen and actually play with it real time. You can go click and see how it behaves, how that it plays something, how it transitions. Everything was very, very clear and visible in real time. We are able to suggest something and make the changes. Oh, what, how would it look like if this thing is above the other one? What if this panel is below? What if this payment method is on the other side? So we were able to real time discuss in that meeting instead of trying different hypothesis. And end of the meeting, what the designer said was it feels weird not using Figma anymore. So this person is so into cursor to design and build and stuff. Like their core part of thing is missing. Like cursor is a tool like any other tool, right? Like example that that's where things are transitioning and we're able to get very, very quick feedback and bring everyone on board very easily. Now, no matter who the person is, right? A salesperson or a fully technical engineer or a backend guy or someone who's in finance, everyone can come and see very quickly and able to contribute. Before, that was not the case. It was hard for explaining to the audience and the translation layer was there before, but now I feel that has gone. So iterations are faster, which is really exciting.

A (23:09)

And you know, if you come from a world where you prototype something and you miss the mark, you don't have to say, okay, you know, well, we'll be back in three months, we'll be back in, you know, two weeks, right? You can say, okay, let's type something into the exact now and let's see if it can get closer to what you're looking for. Is it, is it quite ready, do you think, to be real time or what sort of the cycle length you're seeing with tools like this now?

B (23:32)

Oh, I would say it's. Yeah, it's real time. Especially with, I mean, depends upon the phase within the lifecycle of the software development in design phase, it's pretty real time. So you can just go type it in thing. This is where using a tool out of box versus customizing the tool for your use case makes a huge difference. Like everyone has access to tools. If you want to use it out of the box, it is not going to give you that much value because you are restarting. So the way you prep it, prime it, so it's much easier to make these quick changes. So that's the groundwork. Like these people, like the designer I talked about, they did the groundwork to get it all ready. So when we go, it's bang, bang, bang, quickly you can see real time. That's also one of the reasons why the camp, the skeptical camp gets frustrated, because out of the box, it's not going to work. When you try two, three times and you give up, like, that's where you actually come and put a layer on the top and make it work for you. So we have not come to a place where out of box it will work. Of course, some companies are able to do this because they're building it from ground up. Ground up, it has every context. So out of box works. So now I would say real time in some of the phases in prototyping, in coding, maybe not real time. It's going to still take some time to have that high quality.

A (24:55)

Are you finding with your team? You know, the example that you gave there is, you know, you take a proprietary solution and you create, you know, sort of a custom version of it. Right. It's not out of the box. It's custom to your environment. And we're hearing a lot about that. Is that where you're getting most of the value versus building any of these tools or systems yourself or using it out of the box, or is it a more of a blend?

B (25:19)

I. I would say more of the value comes from customization, definitely. So there are very. In my day job, right. I would say even for simple. Let's say I want to write a pitch document, right. To share an idea or like, oh, I'm working on an organizational design. I want to run a couple things. Even in that case, I think the tool has context. It makes my life much easier. Otherwise it kind of goes into this zone. It knows its boundaries. If it has the context, it knows what's under my scope, what is not. So it know what to touch and what not to touch. So spending time to preparing and priming will make your team much more productive. It's like sharpening the axe analogy. Just take the time to sharpen your axe so you can cut your trees much faster. Don't just start doing it. It's not going to work.

A (26:10)

I really like that. And it makes complete sense and is a nice, as you said, it's a nice way to take some of the air out of the argument of the, the skeptics and say, of course, you know, it's not just out of the box. We have to, we have to put in the work to make it work for our organization. Shifting gears a little bit Bala. When you think about, when you think about Lyft and the role that data plays within the, the operating model, the business model, the organization more broadly, the, the role that AI plays, you know, can you tell me a little bit more about where and how it plays a role and you know, where maybe it's critical to the organization in a way that just, you know, the average person might not think about it.

B (26:55)

Yeah. I believe across the industry, even as a community of leaders, right. We are having, is in a way we need to all step up and shoulder more responsibility in terms of ethics and compliance and how we think about stuff when it comes to data. Because what end of the day we are doing with AI is we are creating a lot of data one way or the other, right? Either we are building features faster that goes to users and then it creates more data. So we are ethically responsible across. And as a company this is like our top priority. And I'm sure most of the industry experts know and every company is putting a policy first, like hey, having a mindset of data first. Because if that breaks, everything else breaks. Nothing else matters. So we need to pay more attention to data now. It right all the way from security to privacy, like the big spectrum, right? Security is like a threat. Privacy is, hey, it's not a threat. But you should not be doing this, right? You cannot be doing this. Those things. AI in a way has made it easier for access, but that's also the power, right? Like we can make it harder, like we can be more intentional. Things and scenarios which we would not have thought about before to protect, we can now use to protect. So we can build our gates very, very strongly in a way where we are not thinking about it as an afterthought. Data should be front and center. And in this world we know like we are pretty much all the are running out of books to read and we are getting into the synthetic data era where data is being generated and then used for training. So this is where all the data we have is going to be more precious and protecting it and treating it as first class citizen is crucial.

A (28:49)

Are there any sort of guiding principles you can share around how you conceptualize data? Either the protection of it or where it's useful or just how it fits into the broader, you know, strategy and, and you know, Kind of value chain.

B (29:03)

Yeah, I've been working with startups too. Right. One of the things we always talk about is data comes in various forms and shapes, right? But if you don't have a systemic way to identify what is sensitive data, what is not sensitive data, it's going to be tricky. So first have a playbook for your organization. Depends upon which industry, depends upon which what kind of data you're dealing with. And utmost like the topmost thing is always human. You should think about humans. At the end of the day we are all building things for another human in this world, right? It could be a software, but that software used by somebody which is going to add value to someone end of the day. In end of every supply chain there is a human sitting right. And if there is a data that is associated with the human in one way or the other, that's like tier zero, put it that way, that should be super protected and you have to have strong protocols. Then the next comes, okay, transactional data, things that are transient may not make sense two years from now, may not make sense five years from now. So that's the next level, next one stale data system, data log, whatever you want to do, but everything is leaving a breadcrumb. So every data is important, everything is serious. But of course you can't put a protocol to treat everything is the same. So have some framework within like my framework is always like human. First any data around human, super sensitive, then transaction and then systemic stuff and then expand it. Changes based on industry, changes based on the role you play, what kind of models. To be fair, the laws and policies in the governments are catching up. They are not ahead. This is one of the areas where technology has always been ahead of legislations. They are coming and it's very, very hard for a legislation to say what is a sensitive data, what is not. So we all have to own and be responsible. It's common sense and responsibility to do versus if it's not in the law, I'm going to go. So don't rely on law, it's going to catch up. So you create your own rules and like strictly follow.

A (31:18)

And it feels like given the pace of change in technology, what AI is enabling us to do, that this is becoming more pressing rather than less pressing. Do you see it as does AI and some of these new tools that are out there, do they change as you think about how they're going to impact us in the next few years? Do they change any of your principles or any of your approach, or do they just make Them all the more important.

B (31:45)

I would say it's the latter is all the more important because again, humans, right. As a leader, you know, like the most important thing we are here to do is to be there for the humans in the society community. Don't want to be just having one house in the street. That is really good. Rest of the street is messy. Then you don't want to live in that house anymore. Right. Your street is messy. So you have to collectively look at it. AI will make it harder in some ways because of the rapid pace. That's where again, you also have AI to make it easier on the other side. It's on both sides. Both camps will have this. So use it and do not wait until there's a compliance law. You need to follow a new law to follow. If this, I would say all the more important than before makes sense, I

A (32:40)

did want to zoom out a little bit and ask you. There's so much hype around AI right now. There's so many narratives about what it can do, what it can't do. And again, I think you summed it up really nicely about having these two different camps on different ends of the spectrum in terms of the value here. What are some of the common narratives around AI right now that you're hearing more broadly out there in the media that in your experience, you know, are not true or at least are not playing out?

B (33:08)

Yeah, actually if you had asked me this few months ago versus now, like things are changing very rapidly, like by the, like every day there are things that are coming up. It's changing our perspective. So to me, taking a step back, I am keeping a framework in my mind. Right. Hey, your assumptions are going to be invalidated often. So keep re evaluating your assumptions and form new assumptions. Don't stick with the same assumption before. So the common narratives on one side, it's like a boom scenario, right? Oh, A.I. is going to create a lot of value. We are going to have advancements in areas like med medicine. Right. Like protein unfolding and what kind of research can happen in areas like cancer detection and stuff. There's really great, great world. That's where we want to go into. On the other side, the doomsday scenario of oh, losing jobs. We want to have people who are left out. The digital divide, which is real too. Like people are going to be left out, people who do not have access. There are countries and people in the world where they don't even have access to electricity today. So think about that and what will like a very different society it's like fictional movie. So there are both sides of stories. Are there? But somewhere in between, it's going to happen. Right? It's going to happen. It's even. There's a bubble story. Right. Even if the bubble is real and if the bubble bursts, I think it'll come up, come back into a way like every, like every other bubble, like every other crash. So in a new form it'll come. But don't have preconceived assumptions and operate because things are changing. My rule of thumb now is, again, be curious and keep revalidating your assumptions and then you can equip yourself for better.

A (34:59)

I find myself coming back to what you were saying earlier about the 15 to 20% improvement. And, and, you know, just, you know, kind of course correct me on this, but it feels like, you know, what you're saying again here, Bala, is that somewhere between, you know, complete utopia and end of the world, we're seeing steady improvement every year in this technology. Yes. And we're going to keep seeing it march ahead. And that, that is the most like, you know, I'm sure there will be, you know, peaks and valleys, but that's your kind of outlook for the next handful of years. Is that a fair assessment?

B (35:34)

It's a very good summary. Yeah, that, that's the best way to put it. Thank you. And yeah, it's, there's in between and there's going to be progress and there are areas where we want it to go faster, like cancer research. And that will happen. Yeah, steady progress is going to happen.

A (35:49)

Nice. I did want to ask, you know, there's a lot of listeners of this program who are interested in tech and maybe they even work in tech, but not necessarily in a big tech company. They're, you know, in house, you know, enterprise tech, in, you know, any organization in the world. What are some of the lessons that you think that Lyft could potentially teach them? Are the things that, you know, you find that your organization is actually, you know, implementing best practices in that, you know, you're most, you're most excited to share with, you know, everybody else in the community.

B (36:23)

Yeah, I, there are two things I want to share. Right. The first one is not necessarily about the size of the company or where you are. It's about the culture. Like, oftentimes we don't look at that when we talk about big companies, small companies or successful companies or game changers. Culture is going to be the differentiator for your company. Like, if people working together, they feel like they are together. They feel like they belong and they are doing something great. That's a very good place to be in. Doesn't matter how hard the competition is, doesn't matter how easy the competition is. Like, that's a big differentiator culture. Like if you are building a company, if you are building anything, like, think about culture first. Again, coming back to my human thing, right? End of the day, it's humans coming together and doing things. So make that fun. Now more into the business side of things. I would say learn to fail fast and don't worry about pivoting. You don't want to stick to an idea just because you came up with an idea. If it doesn't work, you can always go back and change. That's what everyone wants from you too. You don't want to stick to a failed idea and beat the horse. So the culture or the mindset of failing fast, experimenting and then quickly pivoting is going to be important. Hard decisions are going to be always hard. That's where like priorities and everything comes in. So your decision making loop should be very, very short. Take a decision quickly, move on whether it's right or wrong. I think Bezos, I saw an old video of him, he said bad decisions are better than delayed decisions. Because when it's a bad decision, you know, and then you move on if the delayed decision, you are waiting and then your competition gonna hit you while you wait. So decision making is a principle. I strictly keep it at the high regard. Okay, let's do this faster. Let's fail, move on. Things and other things like tech, depends on which industry, what you are dealing with. Those are all like going to follow if these two things are in place.

A (38:31)

I really like both of those. And it's, you know, it's backing us into a conversation I did want to have around just, you know, your kind of personal philosophy of leadership. What, what makes a good leader and you know, as you think about your role, what do you bring to the table? Or what should a good leader bring to the table to, you know, make their team and ultimately their organization most successful?

B (38:55)

Yeah, yeah, it's. I have always been thinking about this too, like as in my journey, like, hey, what's the secret sauce? Or what's a silver bullet? Or the framework? Every time it comes down to a leader is as good as their team. So first bringing to the table, like bringing the right people to the table is the first job of a leader. So you make sure you build your team by bringing the right people in. And then once you have the right people as a leader, you unleash their potential, right? Like everyone has a full potential. Like as a leader, are you unlocking that full potential in everyone by bringing them together, by doing things that is required to be at their best? So those things, those are the two things I would say a leader can do. Because you could be an expert in a field today and tomorrow something else might come and you're completely new. Like you don't know you are starting from scratch like everybody else. But the two aspects of having the right people in the bus and having those people fully realizing their potential is the biggest differentiator that a leader can bring to the table.

A (40:07)

Technology leadership strikes me as being particularly difficult and in some ways fraught with issues. And the reason I say that, and you know, having lived it firsthand, is the skill set required to be a great engineer or a great technologist is not necessarily the same skill set. That's great to be a manager of engineers. And I'm curious, you know, what sort of mistakes you've seen new technology leaders make and you know, what your, you know, recommendations are or would be for someone who's just stepping into that role.

B (40:42)

Very good question. When I became a manager, one of the things I was told was a, a great leader stays, a great engineer stays as an engineer. An okay engineer becomes a manager. So they always think that oh great, a manager is someone who's an okay engineer. So they became a manager. But that's not the reality. So the one of the mistakes, or even back in the day I had was when you become an manager or a leader from being an ic, an individual contributor, thing is you have learned certain way of doing things and you know, certain things work and when you come in you assume those are going to be the only ways to do things. So if, oh if this is not done like how I would have done this, this is not going to work. So they step in right oh my way like this is how it should be done. Because I have done this and personally it has worked for me. That was one of the anti patterns or mindset to not have another one is the biggest one I would say is trust but verify. Like either managers I've seen, either they don't trust or they trust too much and they don't verify, both are wrong. Like you need to have strike a good balance. Trust, I would say is the one thing that every leader should earn from their team. If they do not have the trust, nothing is going to matter. Going into every conversation as a leader, you Are end of the day, a salesperson, like you're trying to sell an idea, sell something to your team, if they don't trust you, they're not going to buy it. Right. You need to build trust and make that as a foundation so you don't have to worry about how this conversation will land. If I trust you, then I know you are going to tell things that really matters to me and it's in good intention for me. So trust and verify. Having that leverage, rightly done is going to make a leader make like a great or like they're going to break a leader.

A (42:46)

Can we zoom in a little bit to the trust piece? And by the way, I completely agree with you, but I'm curious if you can share a little bit more about, you know, how you do that and you know, how do you build trust? How do you destroy trust? And you know, can you share maybe some stories on each side around how you personally or you've, how you've seen someone build or destroy trust with their team?

B (43:08)

Yeah, they say, a leader I used to work with, they say like, oh, trust comes by foot leaves in Ferrari so you can easily break. So trust happens outside of the room, outside of a transaction, outside of a conversation. So when as a manager or a leader, you're always working towards a goal with your team and there are hard times, right. It's not always going to be roses and everything is great. If you have the trust, it's easy to have those difficult conversations. It's easy to say why something is not working and the way something is done is not good. How to build those things is again, it's outside the room. Like showing that you really care. You are invested in them. You are invested in their growth. That has to happen outside, not during a transaction. Otherwise every conversation becomes heavy and burdened. Like you need to make sure, oh, how, how are they going to take this message? Oh, I need to also give this message. There's two goals you are going into. Keep one goal out, which is I know how they will take it because they trust me. Then just focus on the conversation itself. How it has broken is again, not building trust and purely focused on outcomes and goals and going to a conversation. So I've seen where even I have done this in my past where without building the trust, I would just go and say, oh, we need to do this and this is not the way to do and this is how to do. Then they'll get it. They completely lose trust and nothing works. It's a downward spiral. And I Have seen the other side too. Someone like, there is a old leadership style where, hey, if I say jump, you just ask how high, right? That is actually in a good way. If you see if you have the trust, right? If I know this person is asking me to jump for a reason and that's going to be a good reason, then people will really ask you how high when you ask them to jump. So I tell my team to transition from sell to tell, right? You need to sell when they don't trust you. But once they trust you, you just have to tell them. They will just know. Because if your friend tells you something, you know, okay, this is my closest friend. They're telling me for the right reason. They're not going to try to sell you. Like, if they don't, if you don't trust, then the selling comes in. A leader's transition should be from cell to tell, and that can only happen if you have the trust factor.

A (45:38)

How do you in that scenario balance context? I guess because there's a scenario where you literally just say, do this, do this exact thing, and there's zero context. You can easily imagine, as you said, a cell world where you're completely wrapped up and telling these narratives about, you know, oh, this is having this grandiose impact that may or may not be true. How do you balance that? And what is the right amount of context for an individual contributor? In a trusted environment?

B (46:11)

Yeah, in a trusted environment. Even in a trusted environment, context is the key. Context is going to make a big difference as a leader providing that context. In a way, it's not. I'm not going to sit and make someone fully understand the whole story. It's going to take a couple days to get even to the same page. So that's where Tusk will accelerate that. And one thing I strongly believe, if decisions are made based on information people have in hand, leaders have more information, so they make a certain decision. But when you want to, when you go one level down or one level up, the decision, the information level changes. Like, what kind of information a CEO has is not one. What I have, and I see my team might not have the same. So what can we package, what can we pass and set the context. And if you do it few times, then that's where trust comes in. Okay, I have the context. I know how they are thinking. I know what's going to come into play. Then it becomes much, much easier. Like you kind of gave the key here, which is context and information. Make sure the information is accessible. Information should not be Protected unless it is sensitive and someone should not know something. Otherwise it should be very open. So people. I always believe that if my team has the same level of information I have, they're most likely going to take the same decision that I'm going to take. So that. That's the differentiator that really changed my mind.

A (47:40)

Right. Is your, you know, out of curiosity, is your team primarily remote? Is it primarily on site? Is it a hybrid? And you know, what's your sort of posture for, you know, the right configuration for engineering teams?

B (47:55)

I have teams both in office and remote like, and we have satellite like a different location too. Personally, I have a team in New York, have a team in San Francisco, in Mexico. And then also within us there are people who are remote. So it's all over the place. I believe Covid has done that to most of the companies. Some companies are very strict about RTO mandates and stuff. But for us it's much more assets smoother. There are offices and stuff. In terms of how we operate, it's building again, coming back to building trust or building contact. Some of the things are easier in person for sure. That's where for remote teams, if you have hybrid teams, a leader, you have to be more intentional. You cannot say, oh, it's hard and you are not going to do it. That's not how it works. As you know, there are a lot of things happens outside of a meeting. They talk about this meeting after meeting the way like you go to a meeting, you walk into a meeting with a person, you talk a lot of stuff. You come out of a meeting, you talk a lot of stuff. Those are the things actually changes mind and makes decisions in some cases. So being intentional about avoiding some of them. Like if you think a person who has to be there is not there when you're walking out of the meeting because they are remote, then refrain from having the conversation or have the conversation, but don't finish the conversation. Finish it with that other person who is not in that hallway with you. So being little more intentional is going to be crucial. Because we talk about technology advancement, that means world is going to be more remote. We're going to have different people, different countries coming together to work on stuff. So don't rely on in person only. It's going to be a failure model. But have a hybrid and put everything into right use.

A (49:46)

I like that. I like the return to the theme of intentionality. It feels, it feels like the right approach there. I wanted to briefly address the. You know, there's a narrative in Tech, specifically with engineers of, you know, the 10x engineers, or the idea that some engineers are, you know, an order of magnitude more valuable or more productive than others, which to me is exceptionally interesting in the context of AI and in the context of, you know, 15 to 20% productivity gains. Have you seen that play out in practice? And how does it, how does the, you know, capability variance of individual engineers, whether it's overall or it's specific tasks, impact how you structure your teams and structure your, I guess, completion of work?

B (50:35)

Yeah. Oh, good one. Like now think this AI world, it's like 100x. That's what people are talking about. Hey, 10x is the old school, 100x is the new school. I have seen people who were 10x in one team, but they go to another team, they're not 10x anymore. Right. And vice versa. I feel the 10x I have seen some people do 10x not purely mathematically, but like let's say order of magnitude. And it, it has always come down to the environment, always come down to the people they're working with and what kind of problems they are solving, what are they excited about. So a person who is a 10x in one area may not be in another. As a leader, how you collectively up level is identifying the fit. Oh, if this person going to shine and thrive and grow in that team, in that role in this time, put them there and keep it more fluid and move them around. Oftentimes as a leader we have this cold feet of oh, I don't want to move this person because they are the only critical one. If they go, the team will crumble. Like that's actually a bad idea because you are not letting other people grow number one and you are not unlocking other 10xs who could be there. So always be diligent about identifying why someone is not 10x. If you again going for 10x and then move them and find out which will actually unlock them comes back to our unleashing the full potential, right? How will you unleash full potential is changing the scene or giving a different context, different problem, different skill set, different tools. That is an ideal way versus trying to make everybody 10x in the same environment. It'll definitely break. If you take a race, there could be like 1, 2, 3 top places. That's all 10 people run. End of the day it's always going to be that. So environment will change Human psychology. I highly recommend people read psychology to be a better leader. Human motivations are going to be a game changer than any Other leadership playbooks.

A (52:44)

Well, and it's interesting too, because thinking about what you had said earlier about this tendency toward thinking about it as an industrialization mindset just feels like that's not the right approach here. It feels like it has to be much more individual. That to your point, it's not just, okay, every person is the same and we have a playbook for doing the same thing with everybody. It's how can we figure out how to place people, how to build these teams in a way where, you know, ideally everybody can thrive?

B (53:18)

Yes, yes.

A (53:20)

No, I, I like that and it certainly resonates with me. And you know, I. The, the psychology piece as well, I think is very good advice. Now, you've done a lot of work with teaching young people and, you know, helping mentor folks who are kind of coming up in this space. What's your best advice for them these days? What are the skills that you think matter right now as somebody coming into this space and becoming, you know, a technical contributor or a technical leader?

B (53:50)

Yeah, it's. We talked about this little bit. One thing I would say is like, be curious because the world is changing very, very fast. Like, be curious. Don't kind of give up your curiosity. By the time you start something and you finish a book, things have changed already. Like, that's the rapid phase we are in. Like, be curious and keep an open mind. Also, I'm a little bit worried the way things are going, we are getting more narrow and narrower and like putting ourselves in bubbles. Whatever bubble we can talk about, like, could be your thinking. Like, go out of the bubble, go talk to other people who are in complete opposite of that spectrum. Like, be curious about why there is another camp, why there is something else that is not similar to what you are thinking and how you are thinking. So that will give you a different perspective. Like, we don't want any kind of biases built as we grow and as we build next generation of leaders. So staying curious and trying out because now you have access to everything that people did not have before. Like for us to even get on, get a hand on computer was very difficult versus now pretty much you can run a server in your phone and you can do everything you want. So be curious and keep trying. Like different things, experiment different things. Because we don't know what kind of future leaders we want yet. We are looking for those leaders to evolve and show us what leaders we want.

A (55:23)

What makes you hopeful and what makes you concerned about the future of the workforce and the future of work?

B (55:30)

I am hopeful that we Will have a lot of uncharted territories to go solve for and we will go solve them things that was not a thing before people realized, oh, either this was unsolvable or we have learned to live with these problems and never thought about solving those problems because we know either. Oh, I don't even think we can solve. It's not hard or easy, but I don't think this can be solved. That kind of problems we can solve though. That's my hope. That's my excitement. What I'm concerned is I am really concerned about the digital divide I talked about personally. I know we are leaving people out, we are leaving population out. Not everyone is having access as much as we say, oh, mobile and technology is in everyone's hand. It's really not. It's really not making everyone's life different or better like that. So the divide is growing and that's my only concern. And how do we go and bridge them? How do we go bring them along to us? Like I said, I don't want my home to be the only nice home in the street. I want every home in the street to be good so I can go live in that neighborhood.

A (56:43)

So how, how do we bridge that divide? What, what steps can we take as individuals, as businesses, you know, as a society to start bridging that gap, get

B (56:56)

out there to understand. Like first go see the people. Like, we don't really see people. Sometimes I take train to work, I look at, I try not to listen to podcast or music or anything when I commute because I want to hear and see what's happening out there. And I see everyone is on their phone. Like everyone is just heads down, crossing like a school bus stop. The other day every kid was with the phone, heads down. Like I then remembered in our school when we were waiting for bus, it was always like chatting, running around, like kind of pulling each other's leg. That was not happening. We are putting ourselves, burying ourselves into the screen. So go out, talk to people, go to areas that you wouldn't go travel. And that will help you understand the difference. Once you understand the difference, once you know the problem, human mind will automatically go to solve them. You don't even have to tell them to solve. The problem now is we don't see the problem. Like go see the problem. And that will give you ideas, that will give you inspirations. And we should create that awareness and do that. Like, that's why, like go community volunteering. Those are going to be really great tools like a bootcamp. Fully learn about Something you go to a soup kitchen and volunteer the people you see, the kind of problems they have in your life versus the kind of problem you have in your life. Very, very different.

A (58:17)

And that ties really nicely to the theme of curiosity.

B (58:21)

Right.

A (58:21)

And just learning more about your environment, more about your context, and, you know, enriching yourself by doing that. Bala, there's one more just kind of question I had for you or thing I wanted to cover that resonated with me while I was learning more about you. And I don't know if it's an original quote or if it was pulled from somewhere else, but you were talking about the notion of give before you take. What does that mean to you and how have you put it into your practice, you know, professionally and personally?

B (58:51)

Yeah, I. This is something that really helped me grow in my career and also within my society. I would say oftentimes we go into any relationship or a transaction or anything with the mindset of, what am I gonna get? Like, what's in. What's in it for me? Like, what. What am I gonna gain here? Give before take is what I learned in terms of relationships at work. Mainly. That's where it started. Like when I started talking to people, sometimes I realized that you need as an engineer, right. We talked about the hardest part is working with cross functional people, working with other teams to understand the design and stuff. We always go in and say, hey, I want this, right? We never think about what can I give in a conversation. So building relationships before you actually need to work on something with them has really unlocked, like, don't make it transactional. Start building relationships. Start giving before you take. Then when there is a time where you have to take, it will really be easy and it'll be very accessible. And if everyone does this right, there's a book called what we Owe each other in the Society. Right? Is it could be applicable outside of work too. Like, we always think, oh, if I do this, will my parking lot get better? If I do this, will my commute will get better versus, oh, collectively, can I do something where overall there is benefit? It is selfish, I would say, as much as it sounds. Not because you are the take. When the take part comes, it's going to be higher, but the give part is very, very small. And you can really compound the benefit of the take part. So that has helped me grow in pretty much every angle. Personal, professional, societal, all angles. So I keep that as my mantra. I would say, don't worry about what I'm getting right now. Let me give and then when I need something, it'll be bigger and better.

A (60:57)

That's awesome. I love that advice. I think it's so, it's so interesting. And, you know, there's a profoundness to it. As you said, it's, it is altruistic, but it's not purely selfless either, that it actually benefits. It ultimately benefits everybody at the end of the day.

B (61:13)

Yes.

A (61:13)

Follow with that. I wanted to say a big thank you for coming onto the program today. I've really enjoyed this conversation. We've covered a lot of ground and really appreciate your insights.

B (61:22)

Thank you. Thanks, Jeff. It was very, very nice being here. I'm looking forward to the episode and the future.

A (61:31)

If you work in it, Infotech Research Group is a name you need to know no matter what your needs are. Infotech has you covered. AI strategy covered. Disaster recovery, covered. Vendor negotiation, covered. Infotech supports you with the best practice research and a team of analysts standing by ready to help you tackle your toughest challenges. Check it out at the link below. And don't forget to like and subscribe.