#197 - Beyond Input & Output: Building Outcome-Oriented Engineering Teams - Balki Kodarapu

[00:01:19] Introduction

Henry Suryawirawan: Hey, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me, Balki Kodarapu. He’s an experienced engineering leader and very experienced in a startup as well. So today we’re going to talk about engineering leadership and a few tips from him, how he can make a good culture and those kind of stuff. So Balki, welcome to the show. Looking forward for our conversation.

Balki Kodarapu: Thank you, Henry. Honored to be on this podcast. We connected on LinkedIn a few years ago. I’ve been an avid follower of Tech Lead Journal all this time, and it’s a great honor to be here talking to you.

[00:01:55] Career Turning Points

Henry Suryawirawan: Balki, I always love to ask my guests first to maybe tell us a story about yourself. Maybe any turning points from your career you think we all can learn from you?

Balki Kodarapu: Yeah, so several turning points in my life, but I’ll share a couple that are relevant to this audience. So the first one is I stayed in large companies for the first 10 years of my career. Towards the end of that 10 years, I was really gung ho on growing up the ladder, climbing the ladder in the large corporate setting. So I convinced my leadership team to pay for my MBA, executive MBA degree, which they did. So I went to a very good university, University of Washington in Seattle, to do my MBA. All was great until the last semester where we had this capstone project in entrepreneurship. It was a competition. I was like, oh yeah, this is, this is something like a course and I enrolled into that. And the startup and entrepreneurial bug bit me.

So in that competition, I was so involved. I loved every second of writing the business plan, building a company, building a product. Coming out of that MBA program, I completely changed my direction. I’m like, I’m not working for the large companies anymore. I’m only going to build my own startup. So the advice there, or turning point for me, or anyone listening, is don’t make up your mind going into something major in your life. Just be open to changes in your mindset and what the universe gives you.

Another turning point is, so long story short, I did quit my large company and built a startup with a friend. We ran it for a year and a half, learned a lot. But life happened. We had kids and things like that. So we both decided to exit that startup and go back to the corporate world. And I joined a very fast paced medium sized company as a manager. So that was the first time I was a manager outside of my domain expertise. So in my 10 years in the large company, I knew everything about our product and people and technology, so I got carried away. I thought like I could be successful anywhere in the world. I have so much experience. But I was very, very humbled when I joined this company.

First of all, this was a very developer oriented product. Developers took great pride in what they did. So when I joined, I was being a manager. I was like, yeah, setting up their work, you know, rubbing shoulders with other marketing people and salespeople and forgot all about, I’m here to serve my team, right? So I forgot that I have to build my trust and respect. So I was very humbled in that experience. So again, another turning point for me is that when I join a company, a new team, how I’m bonding with my team is first and foremost the most important thing. So I did not last very long in that company, long story short, but it taught me a great lesson in when joining a new team, how to be a humble and do it with curiosity, when I joined a new company. Be learning, be building relationships and things like that.

Henry Suryawirawan: Thank you so much for sharing your story. I think it’s pretty interesting, right? So I think I was in the same shoe like you, right? Working in a corporate ladder, trying to climb up as fast as I can. But obviously, you know, the startup kind of like enticed me. And, you know, these days I have more interest in joining startups rather than corporates.

[00:05:50] Impact & Outcome Driven Engineering

Henry Suryawirawan: So Balki, I know that you have been in the tech world and also engineering world for quite some time. Today, we’re going to talk, discuss topics about, you know, engineering leadership and all that. Maybe let’s start with the first thing is about leading and inspiring engineering teams. You have something that I find really interesting, right? How to actually come up with a framework so that engineering can create more impact rather than in some engineering teams where they focus a lot more on just input and output. So tell us maybe a little bit of background. How do you come up with this framework?

Balki Kodarapu: Yes, this is not my framework, but unfortunately, I don’t know where I got it from. I heard about it on a podcast and then dug up. The framework is called, Input, Output, Outcome, and Impact. So it’s an escalating way of where to spend my time as an engineering leader and more importantly, where my engineering team is spending their time on, right? So five, seven years ago, input and output themselves were hard for many teams, so people would struggle on how to schedule their work and doing the releases on a cadence and in a predictable way. I believe that more, more and more teams now, because they either they follow Scrum teams or they have a good leader, many teams are able to handle input and output, in my opinion, right? There are still teams that don’t do well with input and output. I probably judge them. But I would say most teams and most engineering leaders are well versed in the input and output.

Where some teams struggle is the outcome and impact aspects of it. So for example, we build features as fast as we can. But many teams are unable to connect that with an outcome. Are the users actually using those features? Is someone paying for those features, right? So if you take a step back, we tend to make that somebody else’s responsibilities. I’m building, I’m doing my best I can, the most beautiful product. It scales infinitely. So why are you not selling, salesperson or product person, why are you not telling me what are the right features to build? To be fair, it’s their responsibility. However, my belief is that as an engineering leader and the engineering team, should be very closely involved in what happens with our product when it goes out to the market. So that’s the outcome.

One example of outcome and how to measure and embrace and make it our own is at last company. What we did was at the start of the demo, we did sprint demos like most companies. At the start of the demo, actually we looked at a software like Pendo, which does user analytics, usage analytics, and evaluated how our features were being utilized in the field. So if you built something in the last print or the sprint before, you would actually look at the corresponding metrics in Pendo and say, oh, we built this, but nobody’s using this part. Is there a gap here? Or if we didn’t market it properly, so on and so forth. So that to me was very empowering to be able to, for the engineering team to be part of that journey. So that’s an example of outcome.

Impact is next level. So the current company I’m helping, is a truly mission driven. Many companies say they’re mission driven, but this one truly is for the first time in my life. So what we do is we help pregnant and postpartum moms live a healthy and joyful experience through those 18+ months during their pregnancy and postpartum. And we do that through technology, obviously. So we help them connect to various fitness devices, like a heart rate monitor, a blood pressure monitor, and a fetal baby heart rate monitor. And based on the data that’s coming in, we provide them guidance on, you know, maybe you could walk a little bit more or your weight is a little bit abnormal, etc. So we literally kind of save lives. So there’s at least two examples where our software and our counselors were able to detect some early signs of trauma and we were able to save the baby’s life.

So it’s very mission driven. But again, like it is very easy for an engineering team to be disconnected for that mission, like be obsessed about the technology because we have so much data. I could drool over that data all day and night long. But reminding them why we are here is an important aspect for me, right? So how are we helping them lead a healthy lifestyle and how can we do that with data. To connect that mission, if not on a daily basis, on a weekly, on a sprintly basis, being able to do that. That impact is the most powerful thing and what I can do in my engineering leadership role.

Henry Suryawirawan: Thank you for outlining this framework, right? So Input, Output, Outcome, and Impact, right? I think I would tend to agree with you based on my experience as well, looking at the different engineering teams in the industry, right? I think somehow, especially as you get bigger, right, and maybe in the small startup, everything is kind of like well connected. You understand the mission, you understand the features you build and the kind of outcome and impact. But as a company, organization grows larger, typically, right, you’ll start seeing silo, information not spreading through end to end, right? And engineering mostly given like, okay, here’s what are the things you need to build, right? So instead of you understanding what are the outcomes that potentially could happen, they are just given, you know, like a list of features and to produce output.

[00:11:52] Helping Engineering Connect to the Outcomes

Henry Suryawirawan: So I think partly, one responsibility for leaders is actually making sure that this doesn’t happen that often and somehow engineers are able to understand the outcome. Maybe in your experience, what are some of the practices or habits outside of maybe like Pendo that you have seen, that you have done before, right? What are some of the things that engineering leaders are able to kind of like help so that engineers don’t forget about this aspect?

Balki Kodarapu: Yeah, several things. So for the last three companies, I always made sure that engineering team spends a good amount of time with our support team, right? So most often, support team is the front line for the pain and the joy of our customers. And again, because of the layers in between, engineers tend to be, we tend to keep them separate. Like you don’t, you can focus on your work rather than being involved in the day to day grind. But I think differently. I feel strongly that engineers should work side by side at least a few hours a day or a few days a month beside the support team and be involved in their journey. So there’s one we do.

And at the current company, we actually have counselors and coaches on staff. So they are the ones that are actually talking to the moms day in and day out. They have a very tough job. They use an internal software we built in order to communicate with these moms, right? So they have to handle dozens of moms every day. Moms go through ups and downs throughout the day. So being able to stand by them and support them is a tough job. So I’ve not done this yet, but my goal is for every engineer that joins spends about a week with these navigators to learn from their journey, right? So they’re so far away from the technology, but we also build our software for them. So first and foremost, we build it for the moms who are going through this journey. And close behind that, we build it for the navigators who are helping these moms. Those are two examples I can think of.

Oh, another favorite of mine is, we introduced this two companies ago. We do these demos, you know, almost every team does sprint demos. Mostly internal facing, maybe to the product partner. But me and my boss introduced, we do demos for the entire company. I was literally sweating when I heard that. Oh my God, in front of the whole company. It was a small company, but not too small. We were about 80 people when we introduced that. 35 or so in engineering, the rest were outside of engineering. Yeah, I mean, long story short, we take the highlights of the last month and we would do a demo to the entire company once a month. And I’ve always followed that practice. I’ll introduce that pretty soon in this company as well. But it’s one of the best one hour of my month, every month, right?

So being able to prepare, doing it with grace and humility to the rest of the company. Believe it or not, this was the most popular meeting for the entire. This would be more popular than the CEO talking to the company, right? As a technology company, everyone in the company cares about our product. Being able to showcase it in a humble manner is a very delightful experience. So I’ve refined it over the years, but partnered with the product managers to see what makes sense, what to share, what not to share, etc.

But the big takeaway for me is that be open to surprise. So many times we build something, we share it and get punched in the face. This is not what we want, you know. So being prepared for that feedback is the key for me if you’re doing it in your own company.

So these are some of the things. Bring the engineering team closer and closer to the front lines. Be humble. Be transparent with what we are building and how we are building.

Henry Suryawirawan: Yeah, so I think one of the key takeaways for me is always try to get closer to the frontline, like what you said, be it the users or be it the support team. And also being closer with the cross functional team, right? For example, the product team or maybe the marketing team. Getting the pulse from the externals, right? Like how our product is being used, what kind of impact or stories that other people got impacted by using our product. I think that’s always helpful.

[00:16:18] Balancing Engineers’ Focus Time

Henry Suryawirawan: And I think I took interest in one particular word that you mentioned. Engineers like to get focus time, you know, doing their craft, doing their work, so they don’t want to bother with all this. Maybe some tips from you, how for engineers not to just prioritize their focus time, deep work focus time, always we say that to other counterparties, but always to have something in the back of our mind to actually understand the outcome and the impact of what we do?

Balki Kodarapu: Yeah, I mean, it’s a fine balance, right? So it’s well known that when craftspeople like engineers do their best when they’re focused. So no way I’m going to take away that focus from them. But schedule this very important outcome and impact focus time as well, right? So one thing that has helped in the past, this was from almost seven years ago when I was New Relic. We had a role called Support Hero. Instead of just escalating everything to everyone and distracting people. We would have one person focused on bugs and helping external teams. And we call them support hero. So they would be the person fully dedicated to helping others outside of engineering for the whole sprint. It’s a little bit exhausting, but I feel it worked out well.

So what they’re doing is a little bit of a sacrifice. So let me hold the fort down with these bugs and escalations while I’m letting you, the remaining six or seven engineers, enjoy your focus time. So that’s the balance we found. That person would also be, at times, be on the support rotation, the on call rotation as well, so we treat them with kid gloves and respect for what they’re doing. But also know that, you know, you have to do this once every four to six sprints, depending on the size of the team.

Henry Suryawirawan: Yep. So I think for engineers, yeah, typically in a live product, right. So you will have support things, the tickets, right, from users, be it from internal or external, right? And yeah, on call or support hero that you mentioned here is a typical practice that we adopt in order for the engineers to actually understand what kind of issues that typically crop up and what kind of maybe impact. Because when you listen to users problems, right, typically you can empathize with their journey and the kind of impact that it created for them. Thanks for highlighting that.

[00:18:46] Key Engineering Metrics: Releasing with Joy & Confidence

Henry Suryawirawan: If engineers or engineering leaders know about the Outcome and the Impact now, one question still exists in typical startup company or tech company is that how do you actually measure, you know, the engineering productivity or the outcome or output itself, right? So I think these days developer experience, developer productivity are kind of like a trendy topic. Maybe in your point of view as well or your experience, maybe you can share what are some of the engineering metrics that you typically use in order to gauge the effectiveness of your engineering team.

Balki Kodarapu: Yeah, DORA metrics. I highly respect DORA metrics. You won’t go wrong with DORA metrics. Within DORA metrics, a key metric is our ability to deliver and ship with confidence and joy, right? So one of my mentors used the phrase, drama free releases. So, when we prepare for a release and during the release and after the release. It’s a qualitative measure, but there shouldn’t be any drama. You shouldn’t have to stay awake, making sure the release goes on a specific date and time, and it shouldn’t take hours and hours to do a release, and it shouldn’t cause issues afterwards, right? So the specific metric there for me is how long does it take to prepare a release? And how long does it take to do the release itself?

At my last company, just as an example, when I joined, it would take the entire week to prepare a release, and then almost 36 hours to do the release. And the context there is, there is some context there. It’s not like we did it for without reason. We were not a multi tenant application, we were a single tenant application. So every one of our customer has their own infrastructure. So which means we had to release, deploy our software into every single environment which would explode, like whenever we had new larger customers that meant we dreaded, because it would be so much more infrastructure and new servers and containers where we had to deploy. And that was not going to change anytime soon, right? So we did it for a reason. The customers wanted, we promised them dedicated environments as part of their security agreement.

So going multi tenant was not an overnight solution. We had plans to do that, but it was not an overnight solution. So anyway, so just the sheer number of servers and containers took hours and hours. Plus, we didn’t have any automated testing. Again, long story short, we deployed a known solution, CircleCI, which I’d used in the past, which is robust and can scale. And then slowly but steadily introduced various layers of testing, unit testing, functional testing, end to end testing, so on and so forth, canary builds, and etc. All the best practices. Obviously, we could not do it overnight, but over a 6 to 9 month time frame, we methodically introduced all these best practices. And very proud to share that, like over time, we got down to about 4 hours, you know. It’s still cringeworthy, four hours to release is still cringeworthy, but in that setting where we had over a hundred customers and thousands of servers and containers, it was a joy to be able to do that.

So, yeah, long story short, I would say being able to release with joy and confidence is a key metric for internally looking, right? So even that after a while it becomes routine for even outsiders. Our CEO was first impressed. Oh, yeah, that’s great. You improved a lot. But then what’s next, right? So I’ll pause there and see if you have any questions or thoughts before I go to my next part of the answer.

Henry Suryawirawan: Yeah. I like what you mentioned, right? A release with joy and confidence and drama free. I think in, still, in many teams, this might not be possible, right? So because either like they don’t have automation or they have separate teams that do the deployment and things like that. Or they just don’t invest time in building all this, you know, internal tooling and capabilities, but they focus more on just churning out code and building features, right?

[00:23:01] Engineering Metrics Other Org Functions Care About

Henry Suryawirawan: So, I think I hear what you said about DORA metrics. And I know that you also have other kind of metrics and maybe internal dashboard that you use to actually project different kind of progress or ability that engineering does to other cross functional teams. Maybe if you can share a little bit on what are those, you know, and to what counterparties, I think that will be great.

Balki Kodarapu: Yes, yeah. So, you know, when I first got introduced to DORA, I still probably remember, like I was so excited. Yes, I’ve conquered the world. Now, I have metrics. So I started sharing that with our, in our executive team meetings. So, first meeting, they were like, oh, yeah, curious. The second meeting, they asked a few questions. By third meeting, when I was showing the same metrics, they were bored. They were like, let’s move on. You know, the point I’m trying to make is, you know, they are fun for an engineering leader and the engineering team to do, and I can pretty much guarantee they would become table stakes or like a little bit boring even for people outside the team, right? So we should still make sure we are delivering with high quality and confidence for internal reasons.

But I see this from the outside in. And what I’ve come up with over time is different metrics and values for different teams that I interact with. So obviously, one of the things that most of the company, including the executive team cares about, is the product roadmap. So, I partner with the product team and make sure we refine and update the product roadmap before it becomes a big deal, right? So many times it would be like the customer start yelling and screaming and then it’s in reverse. Then we have to go back and scramble and create a roadmap. So product roadmap is top of mind for me. And then going one level deeper, again, this is somewhat more internal.

So start with a customer facing product roadmap. And then work backwards to what it means for our technology roadmap. So I’ve learned this several years ago. Many teams do it the opposite, right? So they’re like we want to scale to a million users, and start from there. I would work backwards. And then build the tech roadmap that powers this product roadmap and go even one step further.

All of us know no product roadmap stands the test of reality, right? So, so what we did about seven years ago, I worked with our CTO at a payment gateway company. We came up with four different outcomes for the company. Like when the company’s ready for exit, what would be the turning point? I’ll give you a specific example. So to make my point, so we could be acquired by a larger company or we would sign up a very huge deal. Those are a couple of outcomes, right? And we work backwards. So if you had to sign up a very large customer, that meant we should have very robust disaster recovery. If we were to sign, if we were signing up medium-sized clients, they don’t care about DR. But very large customer sites care about disaster recovery. So again, working backwards.

So what are the features we have to do in AWS? We were in AWS. That meant we were a monolith. So being a monolith and building a disaster recovery plan is not easy. So we have to split that into modules and maybe even microservices. So it’s just an example of how working backwards and also working towards multiple outcomes and see what is common. So in that example, in all of the outcomes, we had to be able to scale on AWS. By the way, we were on a private cloud back then. We were not in a public cloud. So based on that, we made the decision to like, one of our first fundamental steps is to go into a public cloud environment. And that will solve all four different outcomes. By the way, I got excited and I started sharing an example.

But yeah, product roadmap, back to the product roadmap, having a robust but flexible product roadmap is one of the things the entire company cares about. Even when I’m talking to the support team. As you know, engineering and support are joined at the hip, right? So as we scale, that means support gets the brunt of it, all the bugs and issues. So the metric they care most about for obvious reasons is the number of bugs we have active or the time it takes to resolve a bug and going one level deeper. How long does it take to resolve severity 5 bug versus sev 1 bug, right? So those kinds of metrics are important to support teams. So when I met with them once a week, that’s where I started. How many bugs? What’s the trend line for how long it takes, etc? So that’s another metric. Customer are external facing metric.

Lastly, I talk about the people team, right? People, the HR team, they care about how we’re doing with our hiring. You know, these days, hiring is not a most important thing, but it’s still kind of important. Like what is our acceptance rate? So one of the metrics I’m really proud of is when we make offers as an engineering leader, how many people are actually accepting those offers? Even during the peak of the tech market, I was getting close to 100% acceptance rate and that made me proud. So that’s one example. And then how long does it take a typical engineer to fully onboard and become part of the team, right? So that’s another metric. Pulse surveys is another example. So we, at one company, we did quarterly pulse surveys with all the engineers and getting a good qualitative and quantitative feedback from internal team members. That’s a metric that my HR team cared about.

So long story short, again, DORA metrics are great, but they’re very internal facing. When you start to become an exec and interact with leaders from other functional areas, think about what metrics they care about. Whether they’re HR leader, marketing leader, support leader, they all care about different metrics. So think about which ones you want to expose to them.

Henry Suryawirawan: Wow, I think that’s a very good overview, right? So how it actually connects, right? So I like the one that you mentioned, engineers love their own kind of like geeky stuff, right? So DORA metrics I believe is kind of like one of our geek stuff, right? We always try to talk about it. But not all the time, you know, the counterparties actually are interested in, you know, getting into the inner details, right? Because they can’t connect with what they do, right? So I think product roadmap, product delivery is still one big aspect, right? So also coming back to what you mentioned in the beginning about the outcome and the impact, right? If you can’t deliver anything about your product, right? I think you can’t deliver the outcome and the impact.

And I like the working backwards from your product roadmap rather than engineering led kind of improvements, right? We all talk about rewriting, microservice, and things like that. So those typically are like engineering driven. But if you can connect it to your product roadmap or product delivery, I think that will be an impactful project to do, right?

[00:30:33] Setting Engineering Values

Henry Suryawirawan: So I think in all these, definitely people and recruitment is also important, right? Especially retention as well and onboarding, and also the engineering happiness or developer experience these days. Anything that you want to add here on how to make sure that the retention and also the developer pulse survey that you mentioned actually gives you like a high engagement. So maybe this is also connected to your culture. Maybe a little bit about here, culture, values, you know, how to make engineers more motivated?

Balki Kodarapu: Yeah, you know, in the beginning, I translated the company’s values to the rest of the team, and it works well, I think, right? So if you have a good mission, especially a good mission and a clear mission, working backwards from that and connecting how the work we’re doing to that mission is half the battle. In almost every case it works, but it’s not enough, in my opinion. I’ve learned it the hard way. It’s hard to sustain just keep on saying we save lives or we improve the quality of our customers. It gets tiring if you keep on saying the same thing. So at my last company, I actually took the courage to build my own culture, engineering values. So I came up with five values and we’ll dig into them throughout this call.

But that’s one way, right? So it’s a little bit harder for an engineer, it takes a leap of faith to connect to a company mission, especially if it’s broad, right? So for example, many companies say we work in the open. We communicate in the open. It’s somewhat obvious when you say that. Yeah. Who doesn’t want to work in the open? And it’s also being a typical analytical engineer, what does that mean? So obviously it’s the job of the leaders to go one level deeper. But I did that in the form of engineering value.

So to demonstrate, I’ll use one example. So one of the values I created for this company is we always communicate in the open, we celebrate our wins in public, but at the same time, we document our failures and lessons in the open as well. And then I went one level deeper and almost every startup uses Slack. And I feel like most places, they don’t use Slack in an open setting. Like, for example, in every company I join, when I join, I love to look at the stats that Slack sends to the admins, how many conversations are happening in DMs, how many conversations are happening in a private chat, private group, and public group. If you have to guess, almost 85% of the conversations are happening in DMs. I don’t know about the global setting, but when I join a company, that’s what I see first. And I cringe, like why are so many conversations happening in DMs? It can’t be that everything is secret.

So anyway, so what I came up with is a simple hierarchical framework. By default, everybody should be talking in the broadest public channel. If you can’t do that, if you feel like it’s a large group – being shy should not be a reason. Everybody should have the courage to talk in a public group. But if you feel like it’s too large of a group and it’s, it could waste their cycles, then discuss in a private channel that’s purposed, like for a project or initiative. Only if you feel like that’s not appropriate or if it’s confidential, then do a multi-party DM. And the last resort should be a DM. That’s one of the values, like really breaking it down to what communication in public means.

And I’ll share another one. So as soon as I join, I create a template for AAR is After Action Review, which is another name for postmortems, right? Postmortems are negative. After Action Reviews are more neutral or positive. So anytime there’s a sizable failure, we immediately start by writing our after action report and sharing that with the entire engineering team, and sometimes even with the company. In fact, at this company, I shared that with the entire company. This is what happened and how are we going to make it better? What did we do to fix it? And how are we going to prevent it? So that’s the share our failures and lessons in public.

So those are some things in terms of like how to introduce and reinforce the culture. Maybe we’ll go back to your original question, how to increase the engagement, right? So maybe I’ll pause there and see if you want to reframe, or if you want to dissect that further.

Henry Suryawirawan: So definitely, I think I could actually relate to what you’re saying just now, right? So in a typical setup, any companies have values and mission definitely, right? But sometimes those are kind of like too broad, too general, especially for engineering team to actually also kind of like remember all the time, right?

I think, yeah, I agree that we have, we need to have like a one maybe layer breakdown from the company values to engineering values. So I think that’s what the first key takeaway that I take. And I think you mentioned about Slack DM, right? I think this is coming back to the culture. You know, the culture of the countries, nationalities. Sometimes some people are more reserved, right? They don’t dare to share publicly. But I think if engineering leaders advocate sharing in public first by default, right? Do it in open rather than the DM. I think that’s kind of like a good nudge so that we share what we have and not create like too many silos internally within the team.

[00:36:16] How to Create Engineering Values

Henry Suryawirawan: So I think those are like the values, right? So maybe one question related to that, when you set the values as engineering leaders, do you invite, you know, other executives probably, or is it just internal between engineering leaders? Or do you actually come up with your own values? So how do you typically set these values? Because I think some teams may want to create these kind of values. But maybe some of them will just think, okay, here are the best practices from outside. I’ll just take all these values and yeah, voila, this is our values now. So maybe you have a good tips here how to set the values?

Balki Kodarapu: Yeah, I’m smiling, because, you know, that’s the exact thing I went through at this company. The direct answer is it depends on the context, right? So for example, when I said this last time, we had pretty good engineering leaders that had a lot of what I call the context carriers. They had been at the company for a while. They knew the good and the bad and the existing culture and what should change. So I pretty much relied on those engineering managers. So I just set the framework and said, we need to come up with five to seven values. This is what I’m broadly thinking, not even give any hints and let them speak up and do it very collaboratively. So almost 70-80% of the values came from those existing context carriers, I call them.

At this company, the setting was almost the opposite. A very ambitious, but young engineering team that were just like churning and doing a lot of good work. But not like with a great amount of purpose and connection to the mission. Plus also they’re shy and not as much experience doing things like this. So I did invite them to contribute. They came up with some simple ideas, but they were a bit shy and afraid to, like, speak in the open. So I did come up with some based on my best practices and my short tenure at the company, I knew where some of the gaps were. For example, this communication. I saw everybody reaching out to me in DM, like four people asking me the same question in the DM. I knew within a couple of weeks that the culture was more like private and behind the curtain sort of deal. And that became a core value.

Another counterintuitive value I brought to this company is, you know, many companies these days are like we need to move fast. We need to move fast. All right. So the velocity is important. Move fast and break things. That’s kind of a fashion statement. Luckily, we were already, the team was already moving pretty fast but we were ignoring some best practices like testing and smooth deployments and things like that. So what one value I came up with is we take pride in our craftsmanship, which is how we build things. But we also care about everything else in engineering. Writing high quality code, being able to deliver with grace and confidence, things like that.

So what the best practices of engineering were lacking, the speed was already there. So I didn’t say anything about the speed. When I shared with my peers, they were like stunned. They’re like, why are you not talking about speed, Balki? That’s important. I’m like, it’s table stakes already. So I want them to think about the next level or even like the reverse direction. Slow down a little, so we actually do this right.

Henry Suryawirawan: Yeah, so I think definitely, um, it’s contextual, right? Depending on the maturity of the team, like what you mentioned. Or maybe how long the team or the organization has been formed, right? So this is also one cue for you to actually set the culture or the value. So I think taking just best practice to me, sometimes we lose the connection somehow. Like we just feel that it’s too far beyond us. So I think one key takeaway for me as well is that you set the values that is still kind of like ambitious, but achievable, right? It’s not like something that is too far ahead that the team is struggling to actually even relate and connect with the mission itself.

[00:40:18] Communicating Values

Henry Suryawirawan: So one aspect that I typically got frustrated last time, we set the values, maybe the principles, you know, what kind of engineering teams we want to be, right? People don’t kind of like practice that in reality. So how do you actually motivate or make them remember, remind them all the time that the values are important and we make sure that they get kind of like a practice rather than just formalities. You know, you put in the docs, you put in the emails, sharing that with everybody, but it’s just like a slogan, right? So maybe any tips from you, how you actually remind engineers to always put values behind them all the time?

Balki Kodarapu: Yeah, yeah. So I would give props to Amazon, right? So Amazon’s leadership principles are so well respected because they start them at the interview stage itself. So I’m impressed how they do it. I did an Amazon interview a very long time ago, like 10 years ago, and the recruiter actually sent me, they still do this, I believe, all their leadership principles and said you should practice them and bring examples. So that’s my gold standard.

So what I’ve been doing is towards the end of the interview, I just share my screen and show these values and see their reaction. I’m like, let’s talk through these and tell me what do you feel about this. You know, most people naturally will agree, but I’m like, which one do you not agree with? Let’s discuss. So that’s one way to even get a feel for, you know, some of the cultural aspects of the values.

Another thing I try to do is when giving kudos to the team members, I incorporate, like this is the value you displayed or engineering value you displayed. So not only say, oh, you know, you worked over the weekend, but because of that, you displayed the specific value, so that reinforces.

A third thing that I want to do which I haven’t done is actually share the values in the company demos. So what I plan to do, you have to wish me luck on this. At the beginning of my company level demos, I’m going to share one or more values, and give an example of how we’ll demonstrate that value in that demo itself or in other words, right? So it’s like wearing our values on our shoulder, and share with the rest of the company.

So these are some ways to reinforce. The third one, again, like full disclosure, I haven’t tried it yet. I’ll see how that works.

Henry Suryawirawan: I wish you good-luck when you share that finally.

Balki Kodarapu: Thank you.

Henry Suryawirawan: Um, definitely the first aspect about Amazon, I wasn’t aware about that, so thanks for sharing that, right? So they even asked the candidates during interview about the principles that they have, and asking the candidates to actually, I don’t know, like, explain maybe from past experience, how they actually like display those leadership attributes. I think that’s probably a good thing for any teams to actually practice, right? So starting from the interview itself, you can kind of like gauge the so called the cultural fit aspect, right, with the candidates.

And the other thing, of course, I think in all these kind of values driven, principles driven, there should be a like a reward mechanism, right? So for people to get incentivized. I know it’s more like, sometimes it’s kind of like a carrot thing, right? So we don’t want people to just get motivated because of the rewards. But I think for things to work really well, people need to have some kind of motivation. It could be as simple as like what you mentioned, right? Giving kudos or sharing it publicly in the company forum. I think that always gives a morale boost for anyone to actually remember the values and kind of like display that all the time. So thank you for sharing that.

[00:43:59] Practicing Gratitude & Curiosity

Henry Suryawirawan: The last topic that I think you mentioned during our pre call is about practicing gratitude and curiosity. For engineers, probably this is something that is touchy feely, you know, kind of thing, right? So maybe a little bit on this, what do you mean by practicing gratitude and curiosity? Maybe how did you come up with this importance?

Balki Kodarapu: Yeah, so when I first became a lead almost 10 years ago, 12 years ago, it was in a large old fashioned company. It was a tech company. But the time, both the timing and the setting was not like human friendly, right? So all of my peers and bosses managed by… almost by authority and title and hierarchy. You have to do what I tell you and that’s your job sort of deal. When I first became a lead, I couldn’t do that to my peers. I was managing all my peers. And luckily, one of my good colleagues, he was my role model. He recommended, Balki, you know, uh, you should listen to this podcast called Manager Tools. I don’t even know if they still exist, but it was my first introduction to podcasts and leadership. It’s called Manager-Tools. And they were two hosts, really funny, but also deep meaningful advice on how to be a good leader. And the whole team was about gratitude and curiosity, leaning from behind. So I absorbed that whether it was right or wrong back then, but that was the style I was attracted to.

Over the years, I refined it, but that’s where it all started for me. In terms of putting that in practice, for example. When I join a company, I try to get closer to the team members even if there’s multiple layers, directors, managers, etc. I like to connect with each one of the members one-on-one and on a very personal level. So their family, their hobbies. You know, again, it’s not everyone is open to it, but I kind of tired them out and extract the details from. Over time, they’ll confide in me and share things. Some people are more open. Some people, it takes three or four sessions to know that. I’m not encroaching their privacy. It’s just genuine curiosity, right? So, knowing those and being able to reconnect on those, you know. People are interested in home automation, robotics, Legos, video games. I’m not into all of them, but I also use this as an opportunity to learn.

At my last company, several people were into home automation. So I wasn’t as much into it, but after talking to several of them, and when going to their, they even had their own group meetings. So joining those group meetings, I got into it, right? So that’s the curiosity part. Showing that genuine interest in what other people are interested in. Video games. I never got into video games, but I ask the engineers about what’s the latest and greatest video game and who are they playing with? So it must be similar to you, but most engineers, like that’s their bonding experience with their colleagues, right? So they play video games with each other. Uh, honestly, I couldn’t get in, but I, I still, I’m curious about it.

In terms of gratitude, I already shared about whenever I join a company, the first channel I create is either kudos or shout-outs. And then, once or twice a week, I have a reminder on my calendar to see what’s the highlight, who went above and beyond, who practiced that engineering value well, and then tag them and their boss, whether it’s on our team or external and give a very thoughtful shout out to the folks. And believe it or not, within like a few weeks, that becomes the most active channel with all the reactions, right? So everybody likes to be recognized and appreciated. In fact, like one of the managers, he actually used that as a, like he would go to that channel when he was writing the performance review, because that’s the best way to see what all accomplishments people have. And if somebody comes to me and praises somebody else, I’m like, don’t tell me, I’m closing my ears. Go to the shoutout channel and share that with that person and their manager directly.

So those are some ways to really recognize and in a genuine and caring manner. And it helps in the long term. In the short term, it feels like work, but in the long term, I can guarantee it helps.

Henry Suryawirawan: Yeah, so I think it’s really beautiful, the message that you just conveyed, right? At the end of the day, it’s all a human kind of thing, right? So we are not robots, engineers are not robots, definitely, right? So we also have kind of like a feeling and we want to have some kind of recognition from others, right? So I think for any leaders, don’t create some kind of toxic culture where it’s all about work and, you know, delivery and all that. Practice gratitude and curiosity. I think sometimes, yeah, as leaders, to practice curiosity outside of work is something that we need to remind ourselves all the time, right? Not everything is about delivery, right? And also issues. Whenever there’s an issue, right? When things get done, right? So I think that’s a primary focus for many of the leaders. But actually to also be curious about the individuals. You know, maybe do one-on-ones a lot more often and also skip level from time to time, right? And also the kudos channel. I think for those of you who haven’t got this kudos channel, please create it straight away and start giving people kudos.

[00:49:49] 3 Tech Lead Wisdom

Henry Suryawirawan: So Balki, thank you so much for your time. I think I really enjoyed this conversation. There are so many aspects that we can learn from your leadership and practices. So I have one last question that I would like to ask you to end the conversation. I call this the three technical leadership wisdom. You can think of them just like an advice that you want to give to us. Maybe if you can share your version, I think that would be great.

Balki Kodarapu: Yeah. Top three, I would say the biggest one, this is a little more professional. But one of my biggest failures in my professional setting was that first job when I was a manager at a new company. The primary reason I failed in that was I didn’t think in terms of slices of work and phases of work, right? Like the team had this big vision to work in the background and deliver a brand new product in a big bang fashion. I got carried away and I’m like, oh yeah, that’s awesome. And sure enough, like every obstacle that could come our way, either like a conference or an angry customer, you would keep delaying that. And long story short, again, like that was a, I had a miserable failure. It took like 10 times longer to deliver that product. So the lesson there is 99% of the projects or features, you can deliver value within a few weeks. Anything that takes more than two to four weeks, you can chop it down into a smaller phase of work. So deliver value in phases or slices is my first idea.

Second one is be open to failures. In fact, embrace and look for failure. So again, it goes with the first principle, but for most of my life, I grew up in a setting where failure was not okay, right? So what it meant is many times I wouldn’t even venture into doing something. Which college I wanted to, which career I want to pursue. It’s too hard. It’s too difficult. So I won’t even try it. And I just like winning all the time, because I was choosing easy targets. So, you know, I learned. And I, especially with my young kids, I teach them to push themselves, to try harder things. Not to succeed, but to see what happens and learn from that failure or the mistake.

Third one. It’s a little bit about career progression, I would say. It’s okay to be immersed in work and really enjoy and just be focused on what you’re doing for a living. I would strongly recommend though that raise your head once in a while to go back into the community and network and build your personal brand. Don’t overdo it. But I would say for most engineers, they do, even engineering leaders, 100% or 120% is about delivery and getting joy from the craft. I would say allocate 10 to 20%, depending on where you are in your career. So I’ll be honest on this podcast. I target between 15 and 20% these days. Because of the executive level I am in, my personal brand and networking is quite important. So the remaining 80% I’m delivering and having fun in work. But 15 to 20%, I intentionally do those things, building personal brand and networking. So I would recommend that to folks at any level. Especially for engineering leaders, it’s quite important.

Henry Suryawirawan: Yeah. So I think the last one, I could agree with you, right? So because especially the situation in the job market these days, right? It’s quite tough and especially any kind of, uh, situations could happen, be it layoff or change of culture suddenly in one go, right? And if you don’t have this kind of network with community or maybe kind of like network with outsider people and thirdly about the personal brand, right, where you are recognized for some kind of things, right? I think those would tend to open up new doors for you and new opportunities, uh, whenever you need it one day, right? So, I think thanks for sharing that.

So Balki, if people would like to connect with you or they want to get in touch and do a lot more conversation with you, is there a place where they can find you online?

Balki Kodarapu: Yeah, I love LinkedIn these days. I feel like I learn a lot and be able to share my wisdom there. So I’m open to connections on LinkedIn. The only tip I give is don’t send me a blank connection, say something either about this podcast or anything. But write a personal note and I’ll accept your invitation and even have a virtual coffee with you.

Henry Suryawirawan: Thank you for that invitation. So hopefully people can take your invite to get a virtual coffee. So thanks again for your time today. I think we all learn about engineering leadership and good practices from you. So I think thank you so much for this time.

Balki Kodarapu: Henry, thank you so much. I do want to thank you personally, and then congratulate you. Since we connected, I saw two milestones. So you are, you reached the 10k downloads milestone on Spotify. Is that correct? Recently?

Henry Suryawirawan: 10,000 subscribers.

Balki Kodarapu: Subscribers on Spotify, which is amazing. And then you were featured alongside some cool startups. So that, that one made me smile, you know. As a podcast featured alongside startups. Only Henry can do that. So thank you so much.

Henry Suryawirawan: Thank you so much for the appreciation. It means a lot to me.

– End –