Subscribe
Share
Share
Embed
Explore your curiosity - Interesting people with fascinating stories.
Life consists of three things:
-The stories we tell others
-The stories others tell us
-The stories we tell ourselves.
Balki, welcome aboard to the show. Thank you so much for joining us today.
Speaker 2:Thank you, Ari. I'm really excited. We connected via LinkedIn, and I'm, excited to chat with you today.
Speaker 1:I so what was the moment, right, the earliest moment that you can remember in your childhood where you were like, I I love engineering. I love software, hardware, whatever. What was that first memory for you?
Speaker 2:Yeah. The first memory was probably when I was five or six. You know, I grew up in India, relatively lower middle class family. We didn't have a lot of toys or luxuries, but I figured out how to build cars using matchboxes, and I have some very beautiful memories from that time. I My goal was to race cars back then.
Speaker 2:Building those, matchbox cars was a means to an end, but building that those cars was, like, got me into engineering, the mechanics of, laws, etcetera.
Speaker 1:Who got you into this? I mean, was this just you on your own and the Internet I'm I'm gonna assume that we're of similar age. The Internet wasn't a thing when we were growing up. Definitely not. So I'm assuming you're, like, in your mid forties, something like that.
Speaker 2:Yep.
Speaker 1:How did you get into this? Was it books? Was it parents? Was it family? Was it an uncle?
Speaker 1:How how did this happen?
Speaker 2:I have to admit, I I don't remember distinctly. It has got to be some neighbors or somebody who I saw, watched them do it and then just got fascinated and took it to the next level. So since then, anything that moves and has wheels has been my fascination.
Speaker 1:I remember, for me, it was standing behind my brother when he was basically running DOS commands. And he wouldn't answer any of my questions. If I asked him a question, he barked at me to go away. So I just stood silently behind him listening to looking at what he was doing. That's that's how it started.
Speaker 1:Very cool. So okay. So what what what happened? Like, what is the I don't think I've ever heard about match box car racing. What exactly bring our audience with this and explain to us what that means.
Speaker 2:Yeah. I mean, it was a way to find, Find, like, joy in things that I could not afford. Right? So I I couldn't afford real cars or real toys, but this was a way to spend hours in my backyard in my summer playing with cars and visualizing a movie I watched. So like this this was so long ago that Indian movies, at least my regional language movies, didn't have cars.
Speaker 1:If
Speaker 2:if there was a car in the movie that was like, oh my god, what is that thing? So even visualizing, imagining a car and building stories for hours together, sometimes by myself, sometimes with my siblings or friends. That kept me happy for almost all summer long when I was at that age.
Speaker 1:I love it. And this passion didn't stop at the age of five or six. You went and you studied mechanical engineering, if I'm not mistaken.
Speaker 2:Well, there is a twist there. So when you talked about standing behind your brother, jogged my memories. A few years later, maybe I was 11 or 12 in my seventh grade, was my first introduction to computers. So our school brought in, like, a half a dozen computers. This was, a very sacrosanct area.
Speaker 2:We got to, like, see the computers from the windows, but each student got maybe, like, thirty minutes in an entire week to actually touch and do something with them. Mhmm. And, the first time I I went into that room, I can still smell the AC and the computers, probably toxic, the fumes from those computers. But I I still have distinct memory of that smell, and I waited the remaining, you know, hundred and thirty hours to spend that thirty minutes to go into that room and play with the computers. I got started by just playing these games.
Speaker 2:I the game I remember is Digger.
Speaker 1:I don't know if you
Speaker 2:ever thought to play Digger. That was my first introduction to Digger, but it was like a gateway drug, of course. The teachers wanted me to learn some programming after playing with Digger. After the first few weeks, I got into the plain old DOS basic. Yeah.
Speaker 2:That's where I started to see the power, the the almost the unlimited power of what you could do with, programming as long as you don't get into infinite loops and you had to unplug the computer to restart again. But that was my first introduction.
Speaker 1:These are the good old days where you can run out of memory, you can get the computer stuck, and you have to actually, like, push a hard there was a reset button back in the day, people don't know what that is nowadays, my computer doesn't have that anymore, and and a turbo button, the kids won't know what that is. Mhmm. But it it was, it was an interesting time. What what for you ignited that magic? What what was the the thing that you saw in your eyes vision that this this has infinite potential?
Speaker 2:Yeah. At that time, I don't remember even having a calculator. So this was such a leap of faith that I could send some instructions to the computer, and it would spit out, you know, anything I wanted, like loops and if statements and things like that. Felt like magic to me at that point. And I have a funny story.
Speaker 2:So the next summer, I I went on a hunger strike at my home to for my parents to buy me the computer As a precious child, they bought me most things I asked for. They were apparently small compared to a computer. That was the first time they're like, okay. We don't mind if you die, but we can't afford a computer.
Speaker 1:You'll when you're hungry enough, you'll eat. I I gotta I gotta appreciate your tenacity and dedication. There I I I don't know. I there there is something very rewarding, I think, and this is true for most developers that kinda get hooked. Something very rewarding about the ability to articulate language and for it to be followed and then to get that immediate feedback and to do wondrous things with it.
Speaker 1:Right? Especially, I don't know if you did any computer gaming, to be able to, you know, do math and have these beautiful things appear on the screen. To me, that was the moment where I was like, you know, math equals computer games equals, you know, plus programming. It was just amazing. So and it's hard to hard to come back from that.
Speaker 1:So okay. So fast forward many years, you're okay. So you got hooked on on computers and programming. Why mechanical engineering? Was that back to the the passion for cars?
Speaker 2:Not really. It's it's another twist in the story. So back in India, at least that time, getting into engineering was highly prestigious, highly competitive. So about a 100,000 people would take the exam to join
Speaker 1:IT? Which one?
Speaker 2:Just in my city, Hyderabad.
Speaker 1:Uh-huh.
Speaker 2:Yeah. So that was probably
Speaker 1:I'll mention for our audience is a huge IT Yeah. Hub in India. In fact, I I would say huge amounts of, of my friends, if they're in IT and they're senior executives, they're from Hyderabad. That's probably it's a good guess to to have. Yeah.
Speaker 1:Yeah. So it's it's it's the hotspot. I don't know if it's like that today, but it definitely has been over the years.
Speaker 2:Yes. Yeah. It still is. Bangalore and Hyderabad compete for that first place. They have different flavors, but, yeah, I enjoy going back home to Hyderabad.
Speaker 2:Where were we? So yeah. So getting into engineering was not no small feat. So out of the 100,000, only about 5,000 would actually get into engineering. And even within that, if you had to get into a free program, that would be like only the top 500 folks would get into the free program.
Speaker 2:But long story short
Speaker 1:point just to to help our audience. Right?
Speaker 2:Yeah.
Speaker 1:So that's that's, if I'm doing my math correctly, that's 0.5%.
Speaker 2:Yes. To to get free or subsidized education. Within that, only the top 100 would be able to get any field they want, but 100 to 500, you have to compromise. So that's where the mechanical comes in. It was not my first choice.
Speaker 2:I really wanted to Well,
Speaker 1:it was the first choice, say
Speaker 2:good as science. Yes. Fair enough. Yeah. That was, like, the top 120 students could get in.
Speaker 1:But there's there's there's a magic in mechanical engineering. Did you kind of fall in love with it, or was it a love hate relationship?
Speaker 2:I'll admit it here first. It was a love hate relationship.
Speaker 1:Fair enough.
Speaker 2:I joined the mechanical engineering program, but I vowed to myself, like, the first day I graduate, I'll I'll do something with software and computer. Everybody else in my class made fun of me. It was still even back then, it was still a mystery, computer science, if you can imagine. Late nineties
Speaker 1:Yes. Yes.
Speaker 2:Was not that popular. It was not a field to go after. No.
Speaker 1:In fact, my dad at that time, I was running a BBS with my brother. For our younger audiences, a BBS was basically the first website ever, but you would dial up with a phone to another computer running a service and it's called the bulletin something system, bulletin board system. And basically your phone did these weird noises and then somebody, one person, right? It wasn't the internet. One person dialed to your phone number, connected to your computer.
Speaker 1:That's what I was doing in the nineties. And and we didn't have the Internet. Right? We had these like dial up stuff, which was 2,400 BPS. Was awful.
Speaker 1:It was just awful. You can't you can't even imagine how bad it was, but but we were we were in love. Yeah. So so what was the stuff that you took away from mechanical engineering that in retrospect, not at the time, but ten years later, today, that you're like, okay. I got a lot of value from mechanical engineering.
Speaker 1:What was the things you kind of enjoy in retrospect?
Speaker 2:That's a tough one. But it still goes back to software. So my final year, we did a project, an AutoCAD project as a team. Yeah. And I had really good memories of the practical implications of not just learning to code, but be able to put that into practice.
Speaker 2:That that was my first exposure to be able to do that. And, again, I was even more deeper into love. Like, being the somewhat of a superhuman, in my class of 60, no one cared or wanted to do anything with software. So I was the one, like, furiously typing all of their programs at the last minute. So, you know, I don't know.
Speaker 2:I'm I'm not, like, putting mechanical engineering in a great limelight here. But there's no Yeah. I didn't enjoy it.
Speaker 1:There's no right answers, but, there's there's a passion. I remember at that age, I was, I was building, model airplanes out of Balzac. And, I think there was something magical about learning the the physics and the the physical engineering of it that to date I I'm just I'm obviously big into software, but there's a magic in the physical products and hardware, whether it's a, you know, a model airplane or or a drone basically. Right? Same same thing more or less.
Speaker 1:Awesome. Okay. So fast forward a lot of years. I you you this fire was lit and and never blew out, and now you're in the software industry. You testify that you either enjoy or have just so happened to find yourself coming into complete messes, and to quote you, you call it utter chaos.
Speaker 1:What is utter chaos look like in a software engineering DevOps environment?
Speaker 2:Yeah, so multiple instances, either with people, process, product technology, right? So thing that- So hold
Speaker 1:on, before we go down the five Ms, right, let's talk about the feeling. What is happening? Are people shouting at each other? Is shit breaking? Are customer like, what is the sense of the emotion that you get when you walk into this chaos?
Speaker 1:What does it feel and look like without the technical buzz?
Speaker 2:For for me personally?
Speaker 1:For you and for the people around you?
Speaker 2:I think different people take it differently. For me, early on when I started my career, at least in The US, I had this pseudo mentor that I was able to follow. And I was amazed by how calm he would be in these situations. Right? So that this was almost twenty years ago, but it's still, like, fresh in my memory, Whether it's technical, whether it's piece like, people related issue, he would always be calm.
Speaker 2:So that that's my role model. I don't even think he knows he's my role model. But it's like, I I got to see him firsthand, and I I practiced that for somehow that stuck in my mind. Peace and calm is the way out of this chaos. And, it worked every single time.
Speaker 2:Right? So so yeah.
Speaker 1:What's happening around you though? So you're mastering kind of the zen of moving forward, but what is, what does it look around you?
Speaker 2:Yeah, I mean it's a combination of some people that just giving up. That's the normal persona, right? So early on people like, I don't know what's happening. Count me out of it. That's somebody chickening out.
Speaker 2:And most early stage folks are people who can't take stress. That's what happens. There is these hyperactive out, external processors that are yelling or screaming or, like, blaming even that early in the game. Like, why did this happen? Focusing on
Speaker 1:Yeah.
Speaker 2:The the mechanics and blame versus the solution. Let me let me
Speaker 1:paint the picture. Right? You've got this I mean, you know, I don't I don't think the rest of the world knows the soap opera, which is extreme engineering. Right? Mhmm.
Speaker 1:So it's the crunch time. Right? You need to get the version out. Customers are waiting. They're unhappy.
Speaker 1:Sales is unhappy. The CEO is sitting in the room waiting for you to get it right. And then there's a very awkward meeting where the CEO or somebody important comes into the room and one engineer is depressed and is not talking. Another engineer is mumbling to themselves angrily and another engineer is fuming at the mouth and about to leave the room. Does that sound about right?
Speaker 2:Yeah the situation slightly if you can even paint the picture, I spent my first four years or so in high stakes, technical support organizations. So we were supporting banks. Mhmm. And they would something would go wrong in the middle of the night. We had a plan on how to address it.
Speaker 2:And this would happen in the hallways with, like, ten, fifteen people gathered around computers or a meeting room in the middle of the night.
Speaker 1:Okay. So the crisis happened. Mhmm. Now you're twenty, forty hours into working it. Everybody is exhausted.
Speaker 1:People are at their end of their wire. They don't yet see the end. How do you navigate that situation? Right? People are exhausted.
Speaker 1:People are tired. You need to get it done. High stakes. Right? Money, life, health care.
Speaker 1:There's different scenarios where this happens. Even manufacturing. Right? You show you those lines don't work. It's millions of dollars a day.
Speaker 1:How do you navigate management of the team and everybody in their different kind of corner of the spectrum? What do you do to bring people together despite the situation?
Speaker 2:Yeah. I have to dig back in back into one of those memories, but, understanding that there are humans involved. Right? So, again, I've seen various spectrum of people. Some people can go on for days without resting or, honestly, I'm not one of them, at least not now.
Speaker 2:So I need need a break to do these things. So, in in those high stakes situations, at least, I had the small luxury of multiple people being able to help, thinking of the succession planning. Like if somebody has to go take their break, how do they hand off? Yeah. During those, you know, the the longest I remember is maybe two, two and a half days where we could not resolve it.
Speaker 2:Communication, that's that's where I learned communication, both internal and external is quite critical. When engineers are heads down in the solution mode, either because of ego or because they want to be focused, they don't lift their head up and report out. So that was my first experience of reporting out is even more important than resolution. So that, you know, gives runway towards, like, okay. We haven't solved this problem yet, but we have eliminated these three things.
Speaker 2:So we have five more paths to follow through. So that's a huge thing, both for internal as well as external stakeholders.
Speaker 1:So so an incredibly important aspect here that you're talking about is actually most of the problem is solved before the problem even happens. Yep. And and and really the the the core of that is planning towards being able to work well as a team. And one of the elements that go into that is the communication patterns that you have. Another element is even the ability to hand over.
Speaker 1:So, know, engineers know this, but the general population doesn't necessarily know this. If you're the only engineer who knows the code, there's no way in hell a different engineer can walk into that. It's just not possible. It's almost like learning a new language. So having code reviews, having communication happening on early, having these overlaps of knowledge, that can actually create the ability for engineers to communicate well and collaborate in an environment of chaos.
Speaker 1:Having, you know, these design architecture reviews, having an architecture written down that you can pull up and say, okay, let's map out where the issues are and what the pipeline could look like of where the failure could be and then map out what are all the alternatives to a solution or to finding the problem. These things happen way in advance of the hopefully of the problem. But if you have it all set up right, you you can rock through it beautifully. It's still difficult. It's still tension.
Speaker 1:You still need to do a lot of work, but it's a whole different ballgame. So I mean, you're you're kind of hinting and kind of alluding to these things, but I wanted to just put it out. These practices that you're describing, incredibly, incredibly important. I wanna I wanna touch on a on I think one of the biggest issues that I see. Issue happens and every engineer comes up with, oh, this is the problem.
Speaker 1:But nobody stops necessarily and says, okay. Let's map out the whole pipeline end to end, client to server, whatever, and and map out every single problem that can happen through the pipeline and then do divide and conquer analysis. They just go and start researching a specific problem. Have you seen that happen in your interactions? And and how do you navigate that in real time?
Speaker 2:Yeah. I was about to go there. So this role model of mine, that that was his other attribute, is stay calm and then map out these things, right, where the the touch points, where there's fragility in the system. Yeah. And, noting those and sharing that so we could methodically go through this, look at these logs, look at back then, like, we didn't have any sophisticated, observability like today.
Speaker 2:No telemetry. No it was all, like, hard coded through ugly log files. Oh, that those log files give me nightmares right now. All text files are if he were had the luxury, they would be in some database where you could do some filters. But it it they were still, like, traces and evidence splattered across the system.
Speaker 2:Somehow he would magically know. Or like, I think it's more about the framework, mindset of let's take it step by step, almost like you said, started with the beginning in mind. So like, map it out and see the logs, examine the logs at each of those, points. And then we didn't hesitate to add additional logs, right? Okay.
Speaker 2:Absolutely. We think it could be here, but we don't have the evidence. So, have the courage to real time add add a log statement and deploy it to production with millions of customers.
Speaker 1:You use that word evidence. I mean, this is a game of forensics. Right? You're looking for evidence. You're looking for for what leads to what you're coming up with a hypothesis of what might be the issue, and then you try to prove it out by adding log statements.
Speaker 1:Like, it it truly is a a, you know, CSI, basically. So I have a question to you. Do you see kind of the younger engineers coming out of these skills or or this skill that you're talking about, the CSI to look through complex architectures, complex code? Right? Is this a missing skill, or people kind of have it nailed down from your perspective?
Speaker 2:Well, the tooling is more advanced now, but it's a it's a double edged sword. Right? So at one of the companies, we are implementing OpenTelemetry. It it's pretty sophisticated with Sentry and Grafana, all the alerting, etcetera, etcetera. It's pretty sophisticated, but the systems are also more complex than before.
Speaker 2:Back then, it was, like, client server, maybe one broker in the middle. But now it's, like, a gazillion services and microservices splattered all across the Internet, multi cloud, know, third party services, etcetera. So this is my hypothesis. In my experience, it's still been like more of an art than a science, unfortunately. Some people just like, they would be in the company for a month and somehow they become the sage and like somehow can say, Oh, I think that's the problem.
Speaker 2:I've studied a few of those people.
Speaker 1:And it's the same person consistently getting the right answers.
Speaker 2:Yeah. Yeah.
Speaker 1:How? Why? What is the skill? No. Because this is so important.
Speaker 1:Right? How how all the managers are now their ears are perking up, and they're like, how do I find those type of people to hire them? What's the what's the persona? What's the profile?
Speaker 2:I have a list of those people you have to reach out in the office.
Speaker 1:For a fee. For a fee. Course. Yes.
Speaker 2:Yeah. But interestingly, these people are also the ones that are, you know, for a lack of better term, are on the like, they're not a a regular programmer. Right? So they have their kings, personality kings.
Speaker 1:We'll get to that in a second. Hold on. Hold on. We'll talk about the good, the bad, and the ugly. Let's stay on the good right now.
Speaker 1:Yes. So what what if you are now let's talk about hiring. Okay? You're looking for these people that can figure shit out and fast. Is there any characteristic or is there anything that you can test for?
Speaker 1:Because this isn't a this isn't a skill that's easy to test. You can't be like, oh, do you know explain to me polymorphism. That won't tell you if this person is is a super mastermind in in debugging architectures and flows, you just can't test for that so easily. How do you what is there any proxy to which you can say, oh, if they can do this, can do that? Or is it just you get lucky and you fire the people who can't do the job?
Speaker 1:That's an answer too.
Speaker 2:Yeah. I mean, luckily these days, if like 20% of the team, it has this natural ability, I think we can get by. In terms of testing, I've been experimenting with interviews. So two things I do early on, like, have specific sets of questions about the breadth and depth of their knowledge. I have a set of questions that give me pretty good signals.
Speaker 2:And then we're experimenting with, what I've narrowed down to is instead of building something from scratch, from a requirement, or even a lead core type. I I hate lead core type of exams, by the way, so I've never done those. I'll not allow that in my companies. What we have done successfully is take some piece of code, intentionally
Speaker 1:Break it.
Speaker 2:Break it, and then put it in front of them. I've developed a rubric. And to your point, I have at least 20 to 50% of it is how they react to
Speaker 1:this Fix this shit. It don't work. Yeah. I mean, that's okay. That's what I do too.
Speaker 1:This is highly uncommon. I gotta tell you, Balki, I don't see a lot of people doing this. In fact, my tests were so complicated that more than ninety percent of the people failed.
Speaker 2:Oh, wow.
Speaker 1:Yeah. So I was, we were doing reverse engineering basically for, for forensics, and this the work we had to do was so difficult that I built these kind of, you know, break it, try to fix it, And I had, basically everybody fail. And I I didn't do an interview. I just I just had a five minute call and I said, come do the test. If they pass the test, they were 90% there.
Speaker 1:Right? Because everybody else is gonna fail the test. And in fact, I had this one test where I was developing a a driver. Right? And drivers are tricky because if you mess up, you get a blue screen, your computer's dead, restart the computer, like, it's it's a mess.
Speaker 1:And I worked on an issue for, I think it was three weeks. I had to bring the CEO in and together he was really technical even though he was the CEO. Together, we figured out the issue of the driver, and I was like, oh my god. That's brilliant. I saved the code with the bug.
Speaker 1:This is now my test. And I gave people as much time as they needed. And remember, this took me weeks. Right? And I'm always looking to hire people that are better than me, not not worse than me.
Speaker 1:I must have I must have interviewed for that role 30 people.
Speaker 2:Wow.
Speaker 1:And one person got it. And then this is a funny story. So I'm like, you're hired. And then it turns out that she was the girlfriend of somebody who worked in the company. So I basically give her an offer, and then then the boyfriend comes to me and says, oh, by the way, like, we're so I was like, look.
Speaker 1:It's totally fine. You need to report this to HR, but it's not a good idea for two people to work in the same company, also for safety and kind of diversification, but also for politics and, like, I wouldn't do this if I were you. Your girlfriend is one of the smartest people I've seen. Like, she'll find the job easy. I I don't know if you wanna make this decision.
Speaker 1:It's your decision. So she ended up not working for us, but but absolutely brilliant. Right? What took me weeks she did in in almost five hours. So so, yeah, I I absolutely love your strategy.
Speaker 1:It's what I've done as well.
Speaker 2:Part of the strategy is also how they react and how how they approach. Right? Talk talk about this.
Speaker 1:This is true. What what is the diff what's the spectrum look like in cause you're not really measuring binary success or failure.
Speaker 2:Exactly.
Speaker 1:You're looking at how they think through the process of solving the problem. So tell me about that. What do you see? What's the spectrum? And what's good?
Speaker 1:What's bad?
Speaker 2:Yeah. By the way, I have a post on LinkedIn about this rubric. I've shared it. But there's, like, 10 different elements we measure on a five scale. Right?
Speaker 2:So anything from do they get to the solution in the given time?
Speaker 1:Yes. Hold on. The the given time, why is that important? So it doesn't matter if it takes them two hours or half an hour or ten minutes to get to the solution?
Speaker 2:Oh, they'll have like something like an hour. Right?
Speaker 1:Right.
Speaker 2:So do they get some part of it working? So it's completely broken. Are they fixated on perfection or are they fixated on getting some of the program working? So that's important to me because I'm usually helping high stakes b to b SaaS companies. So perfection is not as important as It's
Speaker 1:making progress.
Speaker 2:Exactly. Yeah. So and how they the other thing is, you know, every company I I help is is predominantly anchored on teamwork. So there are projects people work independently, but most projects are team collaboration, which means are they collaborating the team on our side, the hiring team? Are they like heads down, just like slinging code?
Speaker 2:Or are they like raising their head and conversing with the people? Like that's more on the soft skill side. Things like, you know, do they see if there are any unit tests? If there's no unit tests, will they add them? If there are unit tests, do they test, verify if they are working?
Speaker 2:So it's a more holistic way of measuring their more of the mindset. We have, unfortunately, like in to your example, somebody solved the issue in fifteen minutes, but they never talked. It was just through magic or whatnot. We said, like, we didn't say no directly, but we doubled down and measured their
Speaker 1:Right.
Speaker 2:The interpersonal elements of this.
Speaker 1:This is a tricky thing. Right? So there are different types of software and problems that you can hire that person and you would hire 10 of them. And you don't care that they're not talking to each other because you need that kind of brilliance. Mhmm.
Speaker 1:But there's enough fragmentation in the software that you don't actually care. You don't need them because you're just doing like a moving line, and that's what I had in a previous company. Right? You just had to take a phone, connect to the reverse engineering, the binary protocol, like reading the matrix. You don't really need to talk to anybody, you just need to get your work done.
Speaker 1:Mhmm. The problem is that when you talk about these kind of like ERP systems, they're so complicated and need so much communication. There's no way you can hire an engineer that doesn't communicate well. I would argue that you can definitely hire that person, but depends on what's the software you're building.
Speaker 2:Exactly. Yeah. And just to give an example, with the Gen AI, many of the companies I'm helping, we do lots of prototypes more than ever. And there may be an endless stream of work for that type of person. Fact, we are entertaining that persona who's full stack, may not have the best social skills in the world with wide eyes wide open.
Speaker 2:Like you come in, job is to spit out these prototypes, and it works great.
Speaker 1:Magic. Don't don't talk to anybody. I mean, I'm giving these people shit, but but believe it or not, that was me twenty five, thirty years ago. Garbage social skills. Yeah.
Speaker 1:Like, absolutely nothing. I've grown a
Speaker 2:little bit. Found love, though. Like, at one point, I would be like, do not show me your face, but the world makes us better. Right? When the world changes, you have to change with it.
Speaker 2:There is a place, and there's a great place for these folks, I think. I I would love to talk to such folks.
Speaker 1:I I I had a lot of them, so I'll
Speaker 2:give you my list.
Speaker 1:I'll tell you, I hired them. I was looking for them because Mhmm. Here's the thing. Right? You know this.
Speaker 1:A good developer compared to a bad developer, the bad developer will destroy your life, your willingness to to live your company, your code base. You will never come out of it. An okay developer compared to a a a one of these people. Right? These great developers, these special minds, they're not 30% better.
Speaker 1:They're 10 they're five to 10 x better, meaning they can do the job of three to 10 people.
Speaker 2:Yes.
Speaker 1:Now that just conceptually, that is is crazy. It's like, okay. So you pay let's say you pay them another 30%. Right? So for every $100, you pay them another $30.
Speaker 1:That's a huge bump in salary. You get totally worth it on an economic standpoint. Right? Totally worth it. Okay.
Speaker 1:So so let's talk about the ugly. We talked about the good, some of the bad. Let's talk about the ugly. These antisocial brilliant people, what are the tips and tricks to manage them? What's the worst nightmare situation you were in with one of your engineers?
Speaker 1:Brilliant, amazing, but, you wanted to pull your hairs out. What did that look like?
Speaker 2:Yeah. The worst kinds, at least in in, like, a medium sized companies, when they go just insult people that they don't know. Right? Like, somebody in the stakeholders would say, you have no clue how complex this is. Even even though it's a subtle insult, like Right.
Speaker 2:Saying that out loud, especially in, like, group setting, like, erodes my credibility. Right? So my not by my, I mean, like, the engineering's credibility
Speaker 1:The group.
Speaker 2:In front of the entire company. So building that is expensive. So that's one type. The other persona is the team members either out of jealousy or out of their bad bedside manners. They just don't want to work with them.
Speaker 2:Even though they're such a great technical person to be around that they could learn from, there's a tipping point where they help me a lot, but I lose my patience and it's hurting my ego, I don't want to work with them. So that's the other negative impact of it. But in terms of helping them, the two main Is there a
Speaker 1:way to manage this? So ego is a huge part. Right? I would call it almost likability, right? Like they're brilliant, but you're grinding your teeth when you're walking with them.
Speaker 1:Is there a way to manage this to the degree that you can actually help them increase their skills to the level that these problems are somewhat or diminished?
Speaker 2:Yeah, yeah. So one specific example is this, many times somehow they're also attached that they have super high integrity. Yeah. And in startups, especially you have to make compromises, right? So they do not take that well.
Speaker 2:We are adding tech debt and they're literally in tears when they see like, we have to stop everything and reduce or remove this tech debt. And it's not practical in a startup. We intentionally build this tech debt or we make a small compromise in like the security stance or whatnot. I mean, those things really, really make these people angry and upset, and it's a hit to their integrity. So one trick I learned is I'll take on the risk, like declare in one extreme scenario I had to Don't bring worry about it.
Speaker 2:The Yeah, bring the CEO in. CEO had to write a letter and say, I understand this risk. If something happens because we are not fixing it, it's on me. It will never be on you or your integrity. And that worked.
Speaker 1:Why? Why why I noticed this pattern too that these incredible engineers have incredibly high integrity. Why is there that link? Have you ever figured that out? Because it it seems to be a pattern.
Speaker 2:I'm not a psychologist. All I know is there's a link. There's a pattern.
Speaker 1:Hey. I'll take it. I'll take your agreements. I I I wonder I wonder I mean, I wonder about that because I see it again and again and again. And the integrity is beyond it's also on the level of, like, doing the right thing and being honest.
Speaker 1:They they might not be the nice they might not be nice people, but honesty is such a high value. Yes. So it's it's like I said something, I said exactly that, and if I made a mistake or I said something wrong, they're ashamed to their core and they will admit it. It's as if, like, some terror, nobody else cares, but they are, like, in in almost in tears. Right?
Speaker 1:Because they made this interesting.
Speaker 2:Yeah. One other tip I'll share is giving them real time feedback. Mhmm. So I used to wait, like, as a young first time manager. I'm like, okay.
Speaker 2:Maybe it'll fix itself and absolutely will never fix So I used to wait till the next one on one, then I moved to Slacking or sending them a message right after something I know or noticed. I took it to one level extreme, which is in the meeting, I made an agreement with those folks. When you slip up and lose your, like, tongue, I'm going to stop you right there. I'm your accountability
Speaker 1:That's dangerous because you're doing it in front of other people. How did that work out?
Speaker 2:But I made an agreement before. Ah, okay. So there was, like,
Speaker 1:cultural agreement with everyone that we're gonna grow together. That's so interesting.
Speaker 2:Especially with individuals. Right? So not everybody would do this. Yeah. But these folks generally tend to, like, in the heat of the moment, forget what they agreed to.
Speaker 1:So they could they had to opt in basically to this culture. Exactly.
Speaker 2:Yeah. Yes. Wow. Most of them opted in.
Speaker 1:Oh, wow. I've never done anything like that. That is so interesting. That's It works.
Speaker 2:It works. I've done it three times. It works.
Speaker 1:Oh, wow.
Speaker 2:Yeah. And many times I'll first offer, like, if I have enough connection with them, I could be the accountability partner or they could choose somebody they trust. So it's a fifty fifty for me. They'll be like, if if there's layers between me and them, they may not be comfortable me being there. Like, I'm already two layers above me saying something in front of the group versus somebody
Speaker 1:else. Yeah.
Speaker 2:So that accountability helps a lot.
Speaker 1:Do you see that that accountability partner that near real time or real time, does that feedback create growth?
Speaker 2:I this is the downside of it. Like, 75 of the times when we had folks like this, it's temporary. It it helps the company. It helps get past that. And it may even, in the short to medium term, they may realize.
Speaker 2:But just because it's it's so deep inside them, startups and fast moving companies are not the right fit. Reflecting on all the people that I encountered, it's in I can count them on my fingertips. They're happier in larger settings where there's built in safety, and it it just works better for them where, one, they have a Niagara scope. They're in this eco chamber where as long as they can make it perfect, they can happily live. Right?
Speaker 2:Startups where they have higher influence and there are more room for mistakes and failure, they struggle. So long story short, I I try to keep them and keep them happy and productive, but eventually, their happy path is to go to a a different setting altogether.
Speaker 1:And I I I there's something interesting. Right? I mean, you can move the knee needle. It does help. But the question is, does it fit kind of the the personality and and is everybody happy even with the immense efforts into kind of keeping everybody in the same in the same ship rowing in the right direction.
Speaker 1:Balki, what an absolute delight. We got to go into some really deep, and I think really important topics today. We have only one question, which is and and we are over time because this was so much fun. We have only one question that is scripted in this show. If you had to go back to one of the hardest moments in your life, what would be the advice that you would give to yourself?
Speaker 2:It's an interesting question. I'm at that age group and stage in my life that I reflect a lot. So maybe I'll answer it as twenty or twenty five years ago, what what I would advise myself. The keyword for me is intentional balance. Right?
Speaker 2:So I focus so much on my career at pretty much, expense of everything else, health and family and relationships. It was the right thing for certain time time period, but not this long. Right? So that's what I tell my kids or younger folks. You can you can make those sacrifices.
Speaker 2:Be focused on your career, but eyes wide open. Things like family and relationships, almost impossible to repair once you have gone past a certain threshold. Money, even health you could recover with some extreme measures. Yep. But relationships are extremely hard to patch up.
Speaker 2:It takes 10 times the effort once once they're on the downhill. So that's what I would tell. Like, you can focus on any aspect of your categories that I say, like health, wealth, career, family, relationships, everything, but be intentional. Like, when you're young, you could make sacrifices. As you grow up, you have to be more intentional.
Speaker 1:Balki, thank you so much for coming on the show. This has been an absolute delight.
Speaker 2:Thank you, Ari.