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. I would say most teams and most engineering leaders are well, worst in the input and output. Where some teams struggle is the outcome and impact aspects of it.
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. Dura 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. So if you have a good mission, especially a good mission and 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. Hey guys, welcome back to another new episode of the Technical Podcast. Today I have with me Balki Koderapu, he's an experienced engineering leader and very experienced in a start up as well.
So today we're going to talk about engineering leadership and few tips from him, how he can make a good culture and those kind of stuff so bulky. Welcome to the show. Looking forward for our conversation. Thank you, Andrew. 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 honour to be here talking to you.
Bulky. 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. Yes. 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 1st 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 that 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 in your mindset and what the
universe gives you. Another turning point is so Long story short I did quit my large company and build a start up 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 technologies. So I got carried away. I thought like I could be successful anywhere in the world, 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 bonding with my team is first and foremost the most important
thing. So I I did not last very long in that company, Long story short, but it taught me a great lesson in with joining a new team, how to be a humble and do it with curiosity when when I joined a new company be learning, be building relationships and things like that. 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 NT's me. And you know, these days I have more interest in joining startups rather than corporates. 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. It's about leading and inspiring engineering teams.
You have something that I find really interesting, right? How to actually come up with the framework so that engineering can create more impact rather than in some engineering teams where they focus a lot on just input and output? So tell us maybe a little bit of background, how do you come up with this framework? 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 5 seven years ago, input and output themselves were hard for many teams. So people would struggle on how to schedule their work and doing their releases on a cadence and
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 engineer leaders are well worst 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. And one example of outcome and how to measure and embrace and make it our own is at the last
company. What we did was at the start of the demo, we did spring demos like most companies at the start of the demo, actually, we looked at software like Pendo, which does user analytics, usage analytics and evaluated how our features were being utilized in the field. So if he 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 he 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 plus 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, etcetera. So we literally kind of save lives. So there's at least 2 examples where our software and our counselors, we're able to detect some early signs of trauma and we were able to save the baby's life. So it, 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. 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, OK, here's what the things you need to build, right? So instead of, you know, understanding what are the outcomes that potentially could happen, they are just given, you know, like a list of features and to produce output.
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?
Yeah, there's 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 frontline for the pain and the joys 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 besides 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. All right, so they are so far away from the technology, but we also build our software for them. So first and foremost, we build
it for the moms. So we're 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 print 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 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 it's one of the best one hours 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 partner with the product managers to see what makes sense, what to share, what not to share, etcetera. But the big take away 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're building and how we are building. Yeah. So I think one of the key takeaways for me is always try to get closer to the front line, 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. And I think I took interest in one particular word that you mentioned. Engineers like to get focused time, you know, doing their craft, doing their work. So they don't want to bother
with all these. 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. Yeah. I mean, it's a fine balance, right? So it's well known that when craftspeople like Engineer 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 spread. 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 beyond the support rotation, the on call rotation as well.
So we treat them with thick glass and respect for what they're doing, but also know that you know you have to do this once every four to six prints, depending on the size of the team. Yep. So I think for engineers, you're typically in a life product, right. So you'll 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. 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 topics. 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? Yeah, Dora metrics. I highly respect Dora metrics. You won't go wrong with Dora metrics. Within Dora metrics, A-Team metric is our ability to deliver 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. Like 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 explored like whenever we had new larger customers that 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 Circle CI which I've 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 bills and etcetera, all the best practices.
Obviously we could not do it overnight, but over a six to nine month time frame, we methodically introduced all these best practices and very proud to share that like overtime, we we got down to about four hours. You know, it's still cringeworthy. 4 hours to release, it's still cringeworthy. But in that setting where we had over 100 customers and thousands of servers and containers, it, it was a joy to be able to do
that. So, yeah, Long story short, I would say being able to release the 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.
Yeah. I like what you mentioned, right, 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 these, you know, internal tooling and capabilities, but they focus more on just churning out code
and building features, right? So I think I hear what you said about Dura 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.
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 meeting. 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, the point I'm trying to make is, you know, they are fun for an engineering leader in the engineering team to do. And I could pretty much guarantee they would become table stakes or like a little bit boring even for people outside the team, right. So we, 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 road map. So I partner with the product team and make sure we refine and update the product road map before it becomes a big deal,
right? So many times it would be like the customer start yelling and screaming and then it's it's in reverse. Then we have to go back and scramble and create a road map. So product road map is top of mind for me. And then going one level deeper, again, this is somewhat more internal. So start with the customer facing product road map and then work backwards to what it means for our technology road map. So I've learned this several years ago. Many teams do it the opposite, right?
So they're like we want to scale to 1,000,000 users and start from there. I would work backwards and then build the tech road map that powers this product road map and go even one step further. All of us know no product road map stands the test of reality, right? So, So what we did about seven years ago, I worked with our CTO at the 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 man, we should have very robust disaster recovery. If you were to sign, if you were signing up medium sized clients, they don't care about Dr. but very large customers 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 not easy. So we have to split that into modules and maybe even micro services. 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 the 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 sell all four different outcomes. By the way, I got excited and I, I started sharing an example. We have product road map back to the product road map. Having a a robust but flexible product road map 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 said one bug, right?
So those kinds of metrics are important to support team. 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, etcetera. So that's another metric customer, our 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. These days, hiring is not the 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 accepting those offers? Even during the peak of the tech market, I was getting close to 100% acceptance rates, and that made me proud. So that's one example. And then how long does it take a typical engineer to fully on board 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, durametrics 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 a HR leader, marketing leader, support leader.
They all care about different metrics, so think about which ones you want to expose to them. 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
stuffs, right? They 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 road map, 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 road map rather than engineering LED kind of improvements, right? We all talk about rewriting micro service and things like that. So those typically are like engineering driven. But if you can connect it to your product road map or product delivery, I think that will be an impactful project to do, right?
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. 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 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, right? 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 values. 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 stacks 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 joined a company that's what I see 1st and I cringe. Like why are so many conversations happening in DMS? It can 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 purpose 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 Adm that's one of the values like really breaking it down to what communication in public name 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 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. So definitely, I think I could actually relate to what you're saying just now, right? So in the typical set up, any companies have a 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 ensuring values. So I think that's where the first key take away 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 country's 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 DMI 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. 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 this kind of values, but maybe some of them will just think, OK, here are
the best practices from outside. I'll just take all these values and yeah, well, this is our values now. So maybe you have a good tips here how to set the values. 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 know the good and the bad and the existing culture and what should change. So 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 7080% 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 we're 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 DMI 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, right? So the velocity is important, move fast and break things. That's the kind of a fashion statement. And 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 A1 Valuer 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?
Bulky, 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? Yep. So I think definitely 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 take away 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.
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? 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 and bring examples. So that's my goal 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 then 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 varying 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. I. Wish you good luck when you share that. Finally, 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 needs 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 moral boost for anyone to actually remember the values and kind of like display that all the time. So thank you for sharing that.
The last topic that I think you mentioned during our pre call is about practising 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? Yeah. So when I first became a lead almost 10 years ago, 12 years ago, it wasn't 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 Baki. You know, you should listen to this podcast called Manager tools.
Don't even know if this still exists, but it was my first introduction to podcast and leadership. It's called manager Hyphen 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 leading from behind. So I observed that whether it was right or wrong back then, but that was the style I 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 tried to get closer to the team members, even if there's multiple layers, directors, managers, etcetera. 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, and extract the details from overtime.
They'll confide in me and share things. Some people are more open, some people it takes 3 or 4 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 went going to there, they even had their own group meetings. So join 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. 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 practice 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 shout out channel and share that with their 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. Yeah. So I think it's really beautiful the message that you just conveyed, right? At the end of the day, it's all 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. 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 will be great. 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. I'm like, Oh yeah, that's awesome.
And sure enough, like every obstacle that could come our way either like a conference or a angry customer, it would keep delaying that. And Long story short, again like that was AI 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. The 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 OK, 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 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 love 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. The mistake. Third one, it's a little bit about career progression. I would say it's OK 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. 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 situations could happen, be it layoff or change of culture suddenly in one go, right? Then 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 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? 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. 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. 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? 10,000 Subscribers 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 starters. Only Henry can do that. So thank you so much. Thank you so much for the appreciation, it means a lot to me.