Will AI Replace Software Engineers? Here’s What Lyft’s Engineering Director Says

Hey everyone, I'm super excited to be sitting down with Bala Mataya. He's the director of engineering at Lyft, an advisor to tech startups. That Bala has built and scaled game-changing products is super cool, but what really got my attention is his ability to blend that with a focus on people and building high-performing cultures. I want to ask him what he sees as the future of engineering teams, and if AI is ready to write the obituary of the software developer, or if something gentler is coming. What is a thought leader like Lyft already doing that we should be learning from? And how should we as leaders be adapting to this brave new world? Let's find out. Bala, I wanted to say a big thank you for joining us today. Maybe jumping right into it. You know, can you tell me a little bit about your outlook for technology and AI in the coming year and the years ahead, and maybe specifically how it relates to the work you're doing and, engineering as a field? Thank you. Thanks for having me, Jeff, from great to be here. I would say the time we are in, it's definitely the most exciting time from technology evolution. We have seen a lot of things from digital transformation to mobile social, a lot of stuff, but I believe this one is really pivotal. I know we have this habit of saying this every time, but this time I feel this is changing every one directly in a much more accelerated way. Coming to engineering, that's my bread and butter, I can day in and day out see what's happening. Like last year what we are planning to do and how the tools were and just few months in what happens. So it is very, very rapidly changing and people are picking up. So I would say it's a period of creation. A lot of things are getting created and that's where we come in as leaders to make sure we create the right things, we create with the right people and we create for the people. So overall I would say one of most exciting times ever in technology era. So how do you see it specifically as you think about the role of engineers and the role of leaders of engineering teams? What are some of the impacts? How is it changing people's their jobs? Maybe both in terms of the way they're approaching problems and then maybe also their level of productivity in your mind. Yeah, yeah. Before I'll come to that point, one thing that is largely changing or it's on the shoulders of leaders now is there are two camps, right? There's one camp which is super excited. Hey, like we want to get everything done tomorrow and with AI we can finish things in 30 minutes. Like days are now looking like weeks and months and the other camp where people who have been working in this using technology and engineering craft, there are some skeptical camps. As a leader I believe it's our job now to bridge these two. Hey, we need dreamers, we need people at that level to dream. At the same time there's a ground reality. So this is where leaders now play an even more crucial role on bridging these two camps and how it converts or how it is being looked at is of course you talked about productivity, right? That's the first thing everyone is coming at. Can I do things faster? A lot of things are focused on how fast can I build? How quickly can I ship something to the market? So as leaders I look at or I use a lens of value creation at more than output like what outcome are you creating? Yes, I can create 20 features. Are we creating at a rate where users are not even able to use it and fully consume and give you the feedback? As we all know we are building things for end users and consumers and customers. If they're not giving you feedback if you don't have a way to get the feedback no matter how fast you build it becomes a nice. So that's where we come in like user proper lens to measure what productivity actually means and what we want out of teams, what we want out of market. So overall like being more intentional is the word I keep telling my team like how are we being intentional in everything we are doing because we are going really fast. I really like your approach in terms of bridging the gap and I talked to lots of people who are on both sides of the gap from the dreamers who want everything right now and think this is completely changing the way every aspect of a company runs and the people who are saying let's slow down and then really deeply understand what's going on here. With the first camp, 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. I've seen the obituary written for software development as a practice more and more frequently now. 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 these two sentiments. How are you finding it? What is it good for? What is it not good for? What do you think is the outlook for this whole profession? Now, 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. Because at that point we go to doctor and say, oh, I see these two 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 vibe coding because vibe coding actually has democratized software development like anybody can come and do within like few problems 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 a artifact that took a lot of time just to convey an idea. Now that cycle can be reduced drastically to show a prototype quickly. However, when we want to talk about productionizing it, I actually putting it out there where it can get shipped and stay afloat without getting sunk. It starts 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 vibe coding and stuff. If until we have a proper God rail, 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 the art and go and do it in a 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 God rails, proper systems and mechanisms. So things doesn't go out of proportion and blow out. 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 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 macro level questions that's coming up and we're seeing it play out in labor market stats and then company press releases is whether these new tools decrease our reliance on software developers and whether they create a world where we just need fewer software developers. The idea being, well, if there's higher productivity, then maybe we need fewer people and they can do 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, this is a world where it's going to be a smaller team or is that in some way just fundamentally misguided? 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 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, productivity is coming somewhere around 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 AI. Without AI, there's no earning statement that gets completed. Quarter learnings 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 other people doing? Are you creating more than what's a consuming aspect? I think fortunately people are not using AI as a reason to cut the theme size and still operating in a model bar. Okay, let's start creating more output, right? If I have 10 people theme, I'm just going to have seven people to deliver the same versus how 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 they might 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 if we have to be vigilant and that's where leaders come in, like being realistic about what you want to promise, what you think is going to happen before calling a hunch because this is dealing with people and life and industry economy. This is like macro impacts for these. I agree with that. 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. 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. As you said, people talking about 80% of their code is written by AI and this notion that you can measure the value of software development by how much code is written. Just people like us who have been there, 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 hands-on keyboards for 40 or 80 hours a week? Yeah, totally. It's true. 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 becomes the count. But for software, actually, this has been a practice even before once upon a time, we talked about a KLOC, right? KiloLens 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 lifecycle, 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 coordinating, checking, testing, validating, verifying, and aligning. Those are the things that's are going to take time. That's why the gain is 10, 15% is maybe, yeah, I can now let my AI agent write a unit test, which I would spend maybe half a day to write or I could date 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 to have the curiosity is going to be the key. An engineer is defined by curiosity always. 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 and 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 or they are more tokens, more money. So being curious and having more critical mindset out as always, engineers are considered as the pessimist in the room. Ever. 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 will know. If you're curious, you will identify everything. It makes sense to me. 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, that engineers and engineering teams are actually interfacing with the rest of the organization and understanding the product, the customer, and the broader business context. Is that a nice to have or a need to have and is AI changing where the value is in that role? It's a must have since day one. It's back in the day when we had traditional waterfall. That's when 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 quotes. 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. Show what I'm building. Get immediate feedback. More important. That is what actually changed. The last 10 years if you look at software evolution, especially after a mobile, event of mobile and apps, it really changed because the end of the day every engineer 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. They're using AI in a way to help them and the context is being built. 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, even more important than ever before. That's exactly what's on my mind is that in this era where it's easier than ever to ship something that you could be subject to this notion of almost like feature slop. Coming back again to what you said about intentionality. 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 what needs to be done and have that guiding light. How do you approach requirements? How do you make sure that 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? It has always been data driven with any new modern text stack. If you're building B2C mainly, it's highly data driven. Like inside driven, you need to experiment what works, what doesn't work. Now, more so than ever, you have the ability. Now, you can reach audiences who you couldn'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. So 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 to have different perspectives. But now with the AI, I see there's a benefit. You can run multiple simulations. You can have them play devil's advocate and tear up your hypothesis. 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 the 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 a build you can lead up to it and then get it. So coming from old school, I missed that waiting game, but still it has opened new doors. So there are benefits to that. I'll take the benefits any day. It's really interesting. And again, it sounds like Lyft is sort of at the forefront as a number of 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 requirements side to build these faster and play out some of the scenarios. Just what paint me a picture. Yeah, I'll tell you a very, very recent funny story. We had a design review. So designers would come and show their prototypes, like meaning mockups. This is a concept. We want to solve this problem because it's a customer facing right or app that every one of us is a customer there inside that room because we all use this app to take our right 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 are being with Figma. I mean, I said traditional or 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 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 it plays something, how it transitions. Everything was very, very clear and visible. And real time we were 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 we are not using Figma anymore. So this person is so into cursor to design and build and stuff like they are, their core part of thing is missing. Like cursor is a tool like any other tool, like example. 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, like a salesperson or a fully technical engineer or a back end 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. And if you come from a world where you prototype something and you miss the mark, you don't have to say, okay, we'll be back in three months or we'll be back in two weeks. You can say, okay, let's type something into the car now and let's see if it can get closer what you're looking for. Is it quite ready? Do you think to be real time or what's sort of the cycle length you're seeing with tools like this now? I would say it's yeah, it's real time, especially with the, I mean, it 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 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 it 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 are 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 is going to still stick some time to have that high quality. Are you finding with your team, the example that you gave there is you take a proprietary solution and you create a custom version of it. 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, your systems yourself or using it out of the box or is it a more of a blend? 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 to share an idea or like 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 knows 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. I really like that. And it makes complete sense. And it is a nice, as you said, it's a nice way to take some of the air out of the argument of the skeptics. Of course, it's not just out of the box. We have to put in the work to make it work for our organization. Shifting gears a little bit, Bala, when you think about what you think about lift and the role that data plays within the operating model, the business model, the organization, more broadly, the role that AI plays. Can you tell me a little bit more about where and how it plays a role and where maybe it's critical to the organization in a way that just the average person might not think about it? Yeah, I believe across the industry, even as a community of leaders, we are having 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 in 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 no 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 will be no like we are pretty much all the elements 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, isn't it? It's crucial. Are there any 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 strategy and value chain? Yeah, I've been working with startups do, right? One of the things we always talk about is data comes in various forms and shapes. 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 what kind of data you're dealing with and utmost. The top most thing is always human. You should think about humans. Like end of the day we are all building things for another human in this world. It could be a software but that software used by somebody which is going to add value to someone end of the day. In the end of every supply chain there is a human sitting. 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 away. 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, still data, system data, log, whatever you want to do. But everything is living a breadcrum. 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 system next 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. And it feels like 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, you know, all the more important? I would say it's the latter is all the more important because, again, humans 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 the house anymore, right? 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 and you will not follow. If this, I would say all the more important than before. Makes sense. I did want to zoom out a little bit and ask you, you know, 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, you know, 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 your experience, you know, are not true or at least are not playing out? Yeah, actually, if you had asked me this a 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, AI is going to create a lot of value. We are going to have advancements in areas like medicine, right? Like the 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 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 is 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 other bubble, like every other crash. So in a new form, it will come, but don't have preconceived assumptions and operate because things are changing. My role of thumb now is again, be curious and keep re-evaluating assumptions. And then you can acube yourself for better. I find myself coming back to what you were saying earlier about the 15 to 20% improvement. And just kind of course correct me on this, but it feels like what you're saying again here, Bala is that somewhere between complete utopia and end of the world, we're seeing steady improvement every year in this technology. 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 peaks and valleys, but that's your kind of outlook for the next handful of years. Is that a fair assessment? It's a very good summer. Yeah, that's the best way to put it, thank you. And yeah, it's it doesn't 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. 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 enterprise tech in, you know, any organization in the world. What are some of the lessons that you think that lift could potentially teach them or 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. 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, our successful companies, our 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. It doesn't matter how hard the competition is, it 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 to. You don't want to stick to a failed idea and beat the horse. So the culture or the mindset of failing fast, experimenting, 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 shot. Take a decision quickly, move on. Whether it's right or wrong. I think base is if our old video of MSD, 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 going to 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. I really like both of those and it's backing us into a conversation I did want to have around just your personal philosophy of leadership. What makes a good leader and as you think about your role, what do you bring to the table or what should a good leader bring to the table to make their team and ultimately their organization most successful? Yeah, I've always been thinking about this too. In my journey, 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 your potential right. Like everyone has a full potential, 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're starting from scratch like everybody but the two aspects of having the right people in the bus and having those people fully realizing that a potential is the biggest differentiator that a leader can do, bring to the table. Technology leadership strikes me as being particularly difficult and in some ways, fraught with issues and the reason I say that and having lived at first hand 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, what sort of mistakes you've seen new technology leaders make and what your recommendations are or would be for someone who's just stepping into that role. All right, very good question. When I became a manager, one of the thing you were told was a great leader stays a great engineer stays as an engineer and okay engineer becomes a manager. So they always think that oh, a great 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 I even back in the day I had with 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. 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 have 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 up very a sales person. 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 right, he is going to make a leader make a great or a great leader. Can we zoom in a little bit to the trust piece? By the way, I completely agree with you. I'm curious if you can share a little bit more about how you do that and how do you build trust? How do you destroy trust? And can you share maybe some stories on each side around how you personally or how you've seen someone build or destroy trust with their team? Yeah, I can say, I'm going to say, 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, 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're invested in them, you're 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 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 that 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 will get it, they completely lose trust and nothing works. It's a downward spiral and I've seen the other side too. Someone, like, there is an 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, 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 cell 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. The leaders transition should be from cell to tell and that can only happen if you have the trust factor. How do you, in that scenario, balance a context, I guess? Because there's a scenario where you literally just say, you know, 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, you know, 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, you know, an individual contributor in a trusted environment? 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 tests will accelerate that. And one thing I strongly believe if decisions are made based on information people haven't had, 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 is CEO has is not one what I have. And I see in my team, I not have the same. So what can we package? What can we pass and set the context? And if you do it a 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 that the information is accessible. Information should not be protected unless it is sensitive and someone should not know something. Other of you should be very open. So people, I always believe that if my team has the same level of information I have, they are most likely going to take the same decision that I'm going to take. So that's the differentiator that really changed my mind. 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? I have teams both in office and remote, like, and we have a satellite, like a different location to have personally, I have a team in New York, I have a team in San Francisco, in Mexico, and then also within the 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, as is smoother, there are offices and stuff. In terms of how we operate, it's, 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're 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 that 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 that actually changes the 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, well, it's 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 how would I put everything into right use? I like that. I like the return to the theme of intentionality. 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, you know, structure your teams and structure your, I guess, completion of work. Yeah. Oh, good one. Like now, I think this AI, well, 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 off, 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. How will you unleash full potential is changing the scene or giving a different context, different problem, different skills at different tools. That is an ideal way versus trying to make everybody 10X in the same environment. It will definitely break. If you take a race, there could be like one, two, three top places that's all. 10 people run the end of the day, it's always going to be that. So the 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. Well, it's interesting too because thinking about what you would 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. How can we figure out how to place people, how to build these teams in a way where ideally everybody can thrive? Yes. I like that. It certainly resonates with me. The psychology piece as well, I think is very good advice. You've done a lot of work with teaching young people and helping mentor folks who are 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 a technical contributor or a technical leader? We talked about this little bit. One thing I would say is like, be curious because the world is changing very, very fast. Be curious. Don't give up your curiosity. By the time you start something and you finish a book, things have changed already. That's the rapid phase we are in. Be curious and keep an open mind. Also, I'm a little bit worried the way things are going. We are getting more narrower and narrower and putting ourselves in bubbles. Whatever bubble we can talk about, like, could be your thinking. Go out of the bubble, go talk to other people who are in complete opposite of that spectrum. 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. That will give you a different perspective. We don't want any biases built as we grow and as we build next generation of leaders. Staying curious and try it out because now you have access to everything that people did not have before. For us to even get a hand on computer was very difficult versus now pretty much you can run a server in your phone and even do everything you want. Be curious and keep trying 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. What makes you hopeful and what makes you concerned about the future of the workforce and the future of work? 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, 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. 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 you are leaving people out, we are leaving population out. Not everyone is having access as much as we say our mobile and technologies 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. So how do we bridge that divide? What steps can we take as individuals, as businesses, as a society to start bridging that gap? Get out there to understand. First go see the people. We don't really see people. Sometimes I take train to work. I try not to listen to podcasts 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. Everyone is just heads down, crossing a school bus stop the other day. Every kid was with the phone heads down. I remember in our school when we were waiting for bus, it was always chatting, running around, pulling each other's leg. That was not happening. We were 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 it. 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 the awareness and do that. That's why 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. And that ties really nicely to the theme of curiosity. And just learning more about your environment, more about your context and enriching yourself by doing that. Follow, there's one more just kind of question I had for you. The 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, professionally and personally? Yeah. 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 going to get? What's in it for me? What am I going to gain here? Give before take is what I learned in terms of relationships that work mainly. That's where it started. When I started talking to people, sometimes I realized that you need as an engineer, right? We talked about the hardest part is over 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. 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. But 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 will be very accessible. If everyone does this, there's a book called What We O-Each Other in the Society. It could be applicable outside of work too. If I do this, my parking lot get better. If I do this, my commute will get better versus, collectively, can I do something where overall there is benefit? It is selfish. I would say as much as it sounds not because 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. That has helped me grow in pretty much every angle, personal, professional, societal, all angles. I keep that as my mantra, I would say, not worry about what I'm getting right now. Let me give. Then, when I need something, it will be bigger and better. That's awesome. I love that advice. I think it's so it's so interesting. There's a profoundness to it, as you said. It is altruistic, but it's not purely selfless either, that it actually benefits. It ultimately benefits everybody at the end of the day. Yes. Follow that. I wanted to say a big thank you for coming on to the program today. I've really enjoyed this conversation. We've covered a lot of ground and really appreciate your insights. Thank you. Thanks, Jeff. I'm a very, very nice being here. I'm looking forward to the episode on the future. 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.