#19 - Scaling Collaboration Across the Globe - Ranganathan Balashanmugam

Episode Introduction [00:01:59]

Henry Suryawirawan: [00:01:59] Hello, my friend. Thanks for tuning in. Welcome to another episode of the Tech Lead Journal with me your host, Henry Suryawirawan. Time flies so fast, and we are quickly coming to the end of 2020. Due to the pandemic, it is definitely one of the most challenging years that I’ve encountered in my whole life. And I think most likely to many of you as well. And even though the year has brought a lot of tough challenges to us, I hope at the same time that it brings you some resiliency and opportunities to explore new things and bring you to a new level of personal growth. Personally, I have grown a lot myself, including creating this podcast in the last six months, and being able to share my conversations with great technical leaders from the region and around the world. My hope is that the situation gets a lot better in the year 2021, and that hopefully we can all go back to our normal routines and activities. As for this podcast, I will also continue to do my best to bring you high quality contents and stories from amazing guests that I could invite to the show. In order to be able to continue inviting more amazing guests, I’d like to ask a small favor of you to share this podcast with your colleagues and friends, to leave me rating and review on the podcast app, and to join the growing podcast community on LinkedIn, Twitter, and Instagram. Your posts, interactions, and comments would definitely help me a lot to amplify the impact of my amazing guests. And if you are a fan of this podcast and would like to make contribution to the show, you can go to the patron page at techleadjournal.dev/patron, and pledge your support as a patron. I’m currently running a goal on the patron page, and any contribution from you would tremendously helped me towards achieving that goal.

In today’s episode, I had a pleasant conversation with Ranganathan Balashanmugam, or Ranga for short. Ranga is the co-founder and CTO of EverestEngineering, a company that provides software engineering when you need it. He is passionate about scaling and leading distributed teams, where I think most of us can relate to, with the remote working becoming a norm nowadays. Ranga shared with me his insightful views on how to lead a distributed team by taking parallel from distributed system, how to overcome challenges when building a team with different culture, how to hire and onboard new people to the team, and also how to become a great leader by learning from his multiple interesting parallels and anecdotes. Another interesting thing that Ranga shared with me in this episode is regarding his trip to conquer the Mount Everest Base Camp, a trip that gave him some unique insights and inspiration, which then led him to start founding EverestEngineering.

I hope that you will enjoy this great episode. Please consider helping the show in the smallest possible way by leaving me a rating and review on Apple Podcasts and other podcast apps that allow you to do so. Those ratings and reviews are one of the best ways to get this podcast to reach more listeners, and hopefully the show gets featured on the podcast platform. I’m also looking forward to hearing any comments and feedback on the social media, or you can also directly send to me at techleadjournal.dev/feedback. So let’s get this episode started.

Introduction [00:05:22]

Henry Suryawirawan: [00:05:22] Hello, welcome to another episode of the Tech Lead Journal. Today I have with me Ranganathan Balashanmugam. I hope I pronounce the name correctly, or maybe I should prefer calling your name, Ranga. So Ranga is someone I know from colleague of mine. I actually saw Ranganathan’s talk in QCon London 2020 on a website. And I find the topic is really interesting, which is about scaling distributed team. I know these days that we are all working probably remotely, and also distributed in terms of a global workforce. And sometimes we have to actually overcome the challenges of working in such manner. So I hope Ranga today will be able to share some of his expertise on how we can actually work in a distributed manner, in a scalable manner, so that we all can work in producing things in a good quality. So welcome Ranga to the show. And looking forward to the chat with you today.

Ranganathan Balashanmugam: [00:06:10] Thank you so much, Henry. Has been great listening to your podcast. And being part of it is still awesome.

Career Journey [00:06:15]

Henry Suryawirawan: [00:06:15] Ranga, maybe before we talk about all these scalable distributed team, you can maybe share with us your career journey so far. So what are your highlights or maybe major turning points?

Ranganathan Balashanmugam: [00:06:24] So I was actually graduated as a civil engineer. And in my final year project, I mostly focused on picking up some interesting stuff on AI, and applied it back. During those days, there was not much internet here. And I basically bought and used AI book from somewhere, and tried to, again, buy some C++ book, because some of the code was in C++, and tried learning it myself during my college, and tried to apply that back in learning some models on a two-ways lab design. And that’s where my journey for transitioning back into Computer Science begin. And eventually, I started liking it. And through campus, I moved into a different part, that is IT. And that’s how I started becoming a software engineer. From there, like it was around 12 years from then, it was continuous, a lot of programming, design, and architectural stuff. And the last thing that I was doing was mostly into working on or learning a lot of distributed systems. And that was quite interesting for me, because suddenly when we had remote systems, the capacity started increasing. And there are a lot of other technologies, like Hadoop, Kafka, Spark, Flink, and a lot of other things that came up during the exact same time. That got me so excited. And I tried that for some time.

And then eventually from there, after 12 years, I took a complete transition into a management cum an operational role. So I moved to a company called Aconex. That’s where I started managing multiple engineering teams at once, and that was at scale, also parallelly managing operations for the company. That was very interesting. That gave me a very good opportunity for leading teams across the globe, and also learning from different teams across. Eventually, after we got acquired by Oracle, and from there, I moved to and started actually a company called EverestEngineering. So I took a break. And went for a one month, actually 22 day trip to Everest base camp, and came back, and I was very clear on what I’m going to do next. And that’s where EverestEngineering started. I’m continuing here as a CTO. And my role is mostly into managing the engineering culture, setting up the software engineering expectations across the company, and mostly operations, and of course, a lot of administrative stuff.

Trip to Mount Everest [00:08:18]

Henry Suryawirawan: [00:08:18] I’m interested when you said that you went to Everest base camp, took a break, and basically try to find out what to do next. So maybe you can share that kind of a journey for people who are probably thinking of, “Okay, I don’t know what to do next.” Maybe you can take inspiration from Ranga here. What happened when you went to Everest?

Ranganathan Balashanmugam: [00:08:35] So when a public company like Oracle buys another company like Aconex, which is another public company, one of the things is it’s a super busy activity, because there’s lots of playbooks that the company starts executing. And it was three different times zones, because I was in India. And Oracle headquarters was in US. And Aconex was placed in Melbourne, which is in Australia. Which means, early morning we start most of the work. And we also have to sync up back during afternoon, during Indian time. And then a lot of calls in the night to match up the US team there. That used to be super, super busy for nine months when the whole transition was happening. So the point was, I was not able to make a clear transition of what I want to do next. And I wanted a break. And that’s when I thought like… It was kind of impulsive. It was not like very planned, and things like that. So within one week, I just decided. I booked the tickets and went to Kathmandu. And from there went to the Everest base camp.

A lot of interesting things that you can do there. One of the most important thing is you don’t have a laptop. And most, at least 99% of the time, you don’t have signals. And the more higher you go, the altitude, the chances of getting a signal is very, very low. So one thing is you have that complete space for yourself. Other interesting thing is you have a lot of personal time, because in the evenings, after 4 or around 4.30, something like that every day, you don’t have a chance to go out much. You can roam around, but you’re like mostly constrained within the space, because it’s too cold, and more higher you go, it becomes more colder. And you don’t have much chance to go outside. That means you have a lot of time where you don’t want to do anything, but you’re sitting in there like a small wooden place. And you have two options. One is like there’s a common hall everywhere where you go, and you chat with a lot of people, and then learn from them, and there’re interesting things there. Or you just sit in the room and just think for yourself without mobile, without laptop, no TV, nothing. So that’s a beautiful time to think for a lot of things. There’re like a lot of interesting things that I learned there. One is the more higher you go, it’s not about the speed. It’s more about the pace at which you go. Anyone can go very fast for 2-3 days. There’s a concept called acclimatization. For the people who don’t know that, it’s a kind of onboarding into a new altitude every time. And you can apply it back to companies or your teams. A simple thing is if you go to a higher altitude, your body needs more oxygen from the air, or like the equivalent oxygen that you need normally, but from the thin air. So the air becomes more thinner. Because of that, our body needs time to change itself, to create more red blood cells. With that, you have like more capacity to absorb the oxygen, and move ahead. So you need to give you your body that time. I’ll tell you, there’s like an interesting thing that happens. So there are a couple of people who are like really rushing forward. And a few people in our group said, “Hey, you should not be rushing forwards. You should slow down and all.” But they ignored. But after one day, we saw them laying down on the ground, because they couldn’t support the oxygen that was needed, because your brain needs time to produce that. The alternative is you take capsules, which produce more oxygen, but that’s not the journey that we want to go in. That’s a shortcut. So that made me like, “Hey, sometimes you have to really go slow, and you have a team, and acclimatize yourself and learn things.” And I always applied that back to learning or like onboarding into a company. You can’t hire a person who is really smart, and then think that, “Hey, they’ll come into your company and start outperforming everybody else.” That won’t happen because they have to first understand the environment. And you need to give them time to connect with everybody else and culture understanding. So different companies have different styles. And that’s interesting because you come back and learn with that. That’s the onboarding and same thing that I tried to learn from that.

And then a few more things, like the more higher you go, you can’t take all the basic things that you want to do. Like everyday bath, you can’t do. It’s too cold. And you don’t sweat much. A lot of the luxuries that you have are limited for yourself. When you come back, the first bath that you take, that’s a big, big luxury. Yeah. So I think these are some of the interesting things that I have. Like, there are a lot of interesting things, but it’s an experience. So you have to actually go there and experience it. And one and only advice I have is don’t rush. Enjoy that whole journey and then come back. There is no point in going there and then racing to reach the top.

Henry Suryawirawan: [00:12:13] Yeah, I can sense they are like, for example, you go into this tough environment. Let’s take an example like, you go into this big company, where everything seems to be very fast paced. And people are smart in a way. So sometimes as a new joiner, onboarding will be such a critical thing. Like what you said, acclimatizing to the company culture, to the company way of working, and workflows, and things like that. I think it’s super important. And I like the way when you said at Everest going to even further to the top, you have nothing. You have no internet. You have no signal, so you have time and space for you, maybe to think about nothing, or maybe to get inspiration and things like that. Sometimes I actually have these kind of moments as well when I go for a walk every evening. So sometimes you have this kind of inspiration somehow going through your mind.

How Ranga Took Management Role [00:12:54]

Henry Suryawirawan: [00:12:54] You have also another interesting story, which I quoted from the talk that you gave, before you took on this management role. Maybe you can share us a little bit about that story, why you dare to take that management role?

Ranganathan Balashanmugam: [00:13:05] Yep. So I started coding like around 16-17 years back. And the interesting part at that point is you have very minimal memory, and then you have like very minimal power. At that point, when you write a code, you run it to the whole, like a simple machine learning training, takes a couple of days. So your whole machine is just running. And if there’s a power cut, the whole thing is gone. You have to restart it. That’s very interesting. And from there, once I started seeing things like the internet, and then you have like servers, the evolution was a very interesting journey. So what it eventually led to was understanding and learning about scaling. And scaling systems was one thing that was very, very exciting for me. So I used to go around, and give talks on all interesting topics on scaling. And I also used to learn a lot about that.

One of the Directors of Aconex, he called me when I was in the previous company as a developer. Initially the conversation started as an engineering manager. But eventually, it moved to Head of Engineering and other things. The thing that he told was very, very interesting, which convinced me to move. One of the things that he said was, “Hey Ranga, whenever you speak, you are showing a lot of excitement about scale. And the most interesting part here is a lot of things that you learned from scaling systems horizontally can be applied back to people.” Then I said, “Do you think the system and people are same?”, then he said, “It’s not like that, but you can definitely learn from parallels. And when you apply, you get a very unique style of management and leadership, and that will be interesting.” So after that conversation went really long. That simple part of the conversation went for at least 30-40 minutes. And then I played on some of the examples from here, and then he gave some context examples on that side. One is on the engineering side and the other is on the people side. Both were interesting. And that really drove me to move into management and give it a shot. I really loved that part where I moved into operations and scaling teams. The results are like quite interesting, but it’s more challenging, because people are more complicated.

Scaling Distributed Teams [00:14:42]

Henry Suryawirawan: [00:14:42] So maybe we can start with this discussion about the scaling distributed teams, taking parallels from distributed systems. So maybe you can start, where do you get this spark of an idea that actually you can treat distributed teams similar to distributed systems. Which part that actually are aligned much stronger? And I know there are obviously emotion part and the human part, which are not probably aligned to the distributed system, but we can start with something that aligns much stronger.

Ranganathan Balashanmugam: [00:15:07] Let us take a simple thing, like a cart. If you take a cart, and then you want to add more load to it, at some point it breaks. At that point, you want to add and take more load. So one of the options is to add a more powerful bull, but it doesn’t scale after that. That’s very hard. The second thing is if you want to buy the most, most powerful bull, then it’s the most expensive thing in the world, and you buy it, and then keep it, but it also has limitations. So the other smart idea is to put two bulls, and then add to the cart, and that’s how it scales, and then start pulling it. So that’s where, like we moved from a core processor into multi-core system. But even for multi-core system, it’s again a single cart. So how do you scale after that? You either take multiple journeys, which is again, time. When we are like trying to optimize time, then you need more units of system. Then you add more bull carts, so that’s where you add 2 bull carts, and then try to pull the load or distribute the load across carts horizontally. Now how do we scale machines similarly? Can we use a single system? Or can we use horizontal scaling of systems where you add more and more machines and you get more power and storage?

But the interesting part there is, the more systems we add horizontally, the harder it becomes to collaborate, because all of the people need to know what is the task that they are doing and how are they coordinating. Which means there’s an in turn some amount of organizing and coordination that needs to take place across people, and that’s where you need proper management and leadership to do that. So that some part of it. But having said that, Hey, you have systems. And then a lot of times if you come from an engineering mindset and move to a management team, they come with the mindset saying that, Hey, now I have a problem. This is solved by five machines in 5 hours. Can I increase the throughput of doubling my machines -ten, and I get half the time. That works for machines probably. But doesn’t work for people. You cannot just pull people in. And then just assume that they’ll take, because people start at different points. And the hard part is the way people collaborate versus the way machines work is different. Machines are just following the protocols. People don’t follow protocols. And it has a lot of emotions and other things involved, which makes it hard to collaborate. But the most interesting part is maybe you get twice the throughput, but if you’re managing well, probably you get 10 times the throughput. That’s more interesting. Because with machines, you know there’re limitations. You can’t go beyond that. Machines are done there. You have to upgrade your machines. Or like the technology changes. That’s what happens. But with people, the interesting part is: if you get all the parts right, the sum of the parts will be definitely greater than adding them together. Yeah.

Henry Suryawirawan: [00:17:22] What do you think are some of these parts? When you mentioned like what things that make these kind of collaboration between people can be more than the sum of its parts?

Ranganathan Balashanmugam: [00:17:30] There are like multiple things, actually. So again, let us talk about… because we are all working remotely. I’ll take a concept called virtual distance, which is from a professor called Karen. What she explained is very interesting, because that talks about a psychological distance between people and how we can work on it. So psychological distance can be broken down into physical distance. And then, there is like a collaboration distance, and I just don’t remember the exact words that we generally use for it, but I think it’s physical distance, operational distance and virtual distance.

So coming back on that. Physical distance is very simple. We are at a different places. So when you have to collaborate, there is actual physical distance. You can’t collaborate that easily. And it grows, right? Like you’re between offices two different time zones. And eventually even within the same company unit, the collocated, if you are from a different organisation and you’re like consultant versus actual employee. There’s some distance. You’re not really connecting at that core level. So that’s what is the physical distance. The second one is operational distance. Operational distance mostly talk about the noise in the system, which means how can you reduce the lag in that connect. Which means how easy is it to just connect with somebody as if it is direct? For example, let us take video calls. If the quality of voice is bad, the quality of video is bad, we lose a lot of time in the noise of the system itself, which is a lot better to ignore. How can we make those systems better or add better tools?

The last part is the virtual distance that we are talking about, which even if you put small time in improving it, it gains a lot of output. A simple thing is communication, for example, or trust. So these are some of the things that will come in this way. And then a lot of work is done in this place and different companies have different states of things. Let us take an example of trust. People all the options that they want to go on, at what level do you? At least most of the people I talk to, they need freedom, which means they need to make their own choices. You can’t impose your choices on them. When you want to do that, you also want them to be accountable. And how does that accountability come, because there’s an expectation gap. And how do you clear the gap is by giving more clarity. And how do you create the clarity’s giving them norms. How do you create the norms? A good example of that would be cities. So let us take cities and, if you’re for example, I’m in Bangaluru. And then I should just go out and there is no much rules about the city. Basically you can’t kill people. But apart from that, there’re basic rules, which can be, cannot break us humans. But apart from that, you are allowed to take your own decisions and move ahead. Should see around behaviors and improve yourself. Let us think I go to a new city called Singapore. When I come to Singapore, I do not buy a rule book about how I should behave in Singapore. I look around. And as soon as I see people, I know that, “Hey, this is how buses work in India. And this is how people go in buses in Singapore.” And probably, by seeing those behaviors and trying to understand and learn from it is when you start learning about it. I’ll give an interesting example. So I know Singapore is mostly modern city. So my assumption was not to carry cash. I came to Singapore and the first day I went around, like a lot of things are very simple, I didn’t have any rule book. And I went on a street and then bought an ice cream. The thing is I also started eating before paying. And then while eating, I just gave him my card. And they said no cards. So the interesting part is eventually I learned that a lot of people use cash in Singapore than cards. So eventually I had to give other standard dollars or other thing, which I had, not a Singapore Dollar. And I had to have that conversation to get it done. But the thing is pretty simple. That’s what we are talking about virtual distance. So this is a very small part of virtual distance where we are talking about freedom, accountability, the framework, or understanding things. And that’s what we can apply back. Like different cities have different cultures, but they have norms on which the city operates. A simple thing is if it is too crowded in India, you can just skip the line and then go ask people do few things, but you cannot do that in few other cities. For example, the first time I went to Dublin, the hard part was me to understand is you have to give a lot of space between people. Because in India, when I stand in the line, I used to stand very close to each other.

So those are the cultural gaps that you can learn, understand and come to a common ground and then move ahead. These are small, small things, but the value of impact of that when you apply it back to a company is a lot better. So let us think how we can apply it back to the team, like for example, let us take an office in Australia, Melbourne, and then an office in India. So Australia, one of the things that you see is people are brought up more independently, so they do take more independent decisions. And the kind of authoritativeness is a lot less. Now, if you take Japan for example, and if you work with Japanese people, it’s very authoritative culture. So the way people sit versus the way people take decisions is a lot more different than again, if you take India. It’s a little bit hierarchical, but because they’re working with a lot of egalitarian companies, there is a confusion because some people try to apply it there and that principles doesn’t work.

So these are the things where we can try to improve the virtual distance, which means there are some things which are very local to a particular culture, but there are like some global things. So the global things is what we can make it as norms, but allow people to be locally right. For example, if you’re going to Japan, and suddenly you are hiring all these people who have worked in hierarchical organization, and you’re not giving onboarding time of a new culture, and then you suddenly say we are all egalitarian, anybody will take their own decisions, it becomes extremely hard. So that’s where the virtual distance become very, very different. And then if an Australian team, Japanese team and Indian team are collaborating, it becomes extremely hard. You have to understand the virtual distance, and then try to improve on that.

Henry Suryawirawan: [00:22:27] Yeah, this is such a interesting concept. Definitely, I’ve worked with global team before as well, like multiple countries, multiple continents. So I can understand that there are norms, there are like what you say authoritative versus independent, hierarchical versus maybe no hierarchy. So these are some of the things that obviously, it’s pretty abstract. So how can you improve your virtual distance, for someone who has just joined a company?

Ranganathan Balashanmugam: [00:22:51] It’s actually a very, very long topic and a lot of things, but I can give you like a few snippets or like a few interesting things that I have learned. So one of the things that I learned is communication is very, very important. As soon as somebody comes in, the most important point is giving them that onboarding time. And if they have not worked with a similar organisation, even if they work within similar organisation, two organizations are not, or never exactly the same. There’s definitely going to be a lot of difference. And each time a person gets added to an organization, the style changes. I’ll give a very interesting analogy, which I like. So if you take boat racing, generally, the way people sit is there are like eight people who sit alternatively. And they actually rode a boat on a reverse direction. And they see the leader of the boat on the other direction. And they watch for hints. Those are the people who are like actually controlling the direction and giving you some more things. But the amount of practice that they take to make it more efficient is just to get all of them on a similar pace. A simple example is even if one of them is more faster, all the effort is gone. The whole direction, the kind of things is gone. Which means how do you collaborate at such a level that you’re all coming to the same point? So I’ll take another parallel so that there are like some minor distances, which will be more clear.

Another parallel is, let’s take an orchestra, which is a very, very good example for collaboration. In an orchestra, assume that you are bringing in a new person who is just doing to do drums. Now, if you don’t give them the onboarding time on the style of the conductor and other things. The hard point for them is that day one if they come, the orchestra doesn’t become beautiful. It’s not that easy. It’s exactly similar to companies. You cannot pull in people from other orchestras, and put it in a different orchestra, and think the music will be same. It’s very hard. Companies are exactly going to be same. As soon as an individual gets added, there is going to be a small deviation. If you put it as a very minutiae graph, there is a change in culture every time a person gets added. And as organisation scales, the cultural part keeps on changing. And that’s where you have to keep on working on the virtual distances. But in an orchestra, there is a conductor. Which is very simple. So there’s a leader who is setting up the direction, setting up the rules. And apart from that, you watch around the behaviors, like the one I said in cities parallel. So you check around watching the behaviors and try to understand, Hey, when this person says (and) moves his hand like that, it means I did something wrong. I need to correct myself. The second thing, if they move a little bit harder, it means you can’t repeat it. It’s like a very hard warning. So that part you understand here. Maybe in another group, they just watch you very seriously. And if you don’t get that cue, it means that you’re not understanding. So that’s the behavior you’re understanding from different cultures. Now assume that two different orchestras to work together. So that’s all like organisations are like working. There are so many orchestras happening. And there should be a master coordinator. That becomes extremely hard.

So that’s why you need to allow the orchestra to be local enough that, “Hey, let it run locally.” But on the top, the music should be same, because we are getting this music at this level, and let us create the same music. The same thing when you apply it back on the rowing of boat, the same thing will not apply, because, in an orchestra versus boat, in rowing, there are eight people. As soon as you change one person, all the time, the person’s pace will be different than all the other people, because they’re practicing a different boat. When they do the rowing again, the interesting part is their pace is going to be different, and all the other seven people are going to change their pace just for that one person. And that’s how the collaboration happens. Now, just assume and apply the same rule back into an orchestra. Assume that the person is playing drums. Can all the whole organisation, all the whole orchestra change its state to match its pace or tempo to drums? No, we can’t. So which means, one thing that’s common at both places, you need to observe the behavior and change it to yourself. But there are like organisation principles and cultural commonness where you need to learn that. And then adjust yourself. That’s one thing. And you need to give onboarding time, like both the places, you need to give them balance to understand the onboarding pace. Then keep on improving continuously.

Onboarding New Joiner [00:26:22]

Henry Suryawirawan: [00:26:22] So is there any such practices, like you can speed up this onboarding time? Obviously, we want every new joiner to be productive. Maybe in the first few weeks or first few months. Is it something like, culture guidance, books, or documents where they can go through? I know that it’s probably not going to be that easy as well. But are there some practices that actually you can use to actually speed up this process?

Ranganathan Balashanmugam: [00:26:43] What we do which was more efficient was to pair and then also promote travel. So first thing I’ll talk about pairing people. So any new joiner who comes from a completely different culture, one is that we spend time on making them understand about the culture, which means spend some time with different people. Give them onboarding. Tell this is how this works, this is how this works. Hey, you need to do that. This is how you do and not. That part is really hard, because right now we are, most of us are on working remotely, which means, we use basically Slack as an online collaboration tool. And a lot of things will be based on the channels that you’re there, and how people behave there online. And you watch people in the calls. But apart from that, we set up a lot of calls to onboard them into the system. You give them some icebreakers. And make them comfortable by learning names and other things. But after that, the other thing that we understood was for them to be able to interact or work with other person. So shadow them or make them comfortable. So a lot of people to move across with the different random people, who will be like playing a play. Most of the time, at least similar roles, because they know what that kind of role expects and the how will each day looks like.

And one most interesting thing that, at least I do at EverestEngineering, was even before releasing the offer, I’ll just tell the how the whole day looks like, so that they will at least try to understand that this is how my day to day looks like. Is it exciting? Not exciting? Should I join or not? Some people may not like the kind of expectations that we have on learning. It’s fine. At least after joining, taking the decision, as you know that this is the expectation that you have. Every week, you need to do this or learn this. They will know that, okay, I’m committing to this and joining, rather than I don’t know that space I’m joining. So it starts before joining. Of course we do all the interviews. But after that, there’s onboarding. And after that, allow people to mingle or paired up with a lot of people. Shadow. And different people are on different paces. So you should give them time to digest. We cannot say that by following this X process, all of them will be improved by, let’s say from 15 days to 10 days. It won’t happen. Maybe for few people, it will be less to two days or three days. For few to be different. So allow them to give that space, and be okay with it. I think it’s more from people who assess our process perspective. So one interesting thing that I learned is a lot of time we come from with us the engineering mindset. And if a company is dominated by a lot of engineers, we try to think everything rationally. When you’re rational all the time, it won’t work like that, especially with people. So you have to apply some rational, which means we can’t say that doing X, Y, Z, will give you something else always. It won’t happen. It’s a variable mix. So, it’s same, right? Like you can’t take a star team, put it in a different company, and we expect the star results. No, it won’t happen. We are part of like very small part of a very big system. And there are like a lot of dynamics within the system that gets obstructed when you do all those assumptions. So sometimes it’s okay to be irrational and allow them to absorb that. And then learn that the acclimatisations should be there. Like for acclimatisation, you have pills. You can take and take that shortcut, that’s fine. But for this, I don’t think there is pills. But it’s more effective and being conscious, and then respecting them, empathizing them, connecting with them. And then, taking feedback from this also important. Because one of the greatest power that they have, which we all don’t have will be, when you’ve paired off eyes on which they will all start looking at each other.

I’ll tell you one interesting thing that I learned. So when we started Everest initially, the small and then few, they were all sitting at the same table. When we wanted to go and have tea or coffee. So tea is like a common thing here. We take tea breaks frequently, like at least three times a day. And we used to go and drink and come back. After we scaled to like 20-25 people, it was hard because all 25 people could not go at the same time. So we said, “Hey, can we move the tea back here?” And then we started ordering tea. And every day at a particular time, we get our tea during breaks. Two times. In the morning once. And the evening. And then there’s class, you take the tea. Then when we grew up to 40 people, suddenly somebody came, and then like, at least they follow the habit of: what is good for you? What can be improved? That’s the feedback that you keep continuously. And when we asked, that person said, “Hey, why don’t you drink coffee?” And then I said, “What do you mean by that? I drink coffee.” Then they said, “In office, there’s no coffee.” Then that’s the first time we realized that there’s no coffee, because we didn’t have the fresh pair of eyes. And everyday assume that they only sell tea here or something like that. Then instantly then and there, we made sure that from next day coffee is there. We took a voting. And then we said “Hey, how many people drink coffee? How many people will drink tea?” Then we started getting two flasks. This may be a simple example, but it can be applied at organization level, when you scale and see a hundred things that you could improve at this level. The same Japanese concept of Kaizen, applies a lot better.

Henry Suryawirawan: [00:30:34] Yeah. I also learned similar concept called radical candor. When you give feedback, as candid as possible, maybe at the right time, obviously. And give examples as well. What you had as an example is about coffee, right? You had no coffee. It’s not about the person doesn’t respect coffee drinker, right? But sometimes it’s just, “Okay, we just didn’t realize. That actually, it’s a habitual thing that we always take tea. And nobody asked for a coffee anyway.” So sometimes it’s just a simple candid feedback that actually can spark us to make a change.

Orchestration vs Choreography [00:31:00]

Henry Suryawirawan: [00:31:00] I’m actually quite intrigued with the orchestra parallel that you gave. When we talk about this orchestration, I always assume, like going back to the architecture principles, orchestration versus choreography. Do you have any take on that? Is there a place for choreography in collaboration within scalable teams?

Ranganathan Balashanmugam: [00:31:17] Can you expand on what choreography means? Just to be clear, like choreography and orchestration the difference?

Henry Suryawirawan: [00:31:22] Yeah. So the orchestra normally is, you have somebody like orchestrator or conductor, who actually guides the people within the team to actually do their parts. While choreography is like in the dance performance, in a team of a group performance, you have people who actually perform as what they think would make a beautiful dance. So everybody knows what they need to do. There’s no single orchestrator . There’s no single master. You can call it in the distributed system. So everyone knows what they need to do, and perform beautifully as a group.

Ranganathan Balashanmugam: [00:31:51] So that part is interesting because, I’ll again take another parallel compared to that. So let us take a orchestra versus military group. So let me complete on. The orchestration part of the conductor and orchestra. So in orchestra, they practice every day, but they know that the finer things comes from the conductor. Which means conductor is not looking at an individual’s mistake. The conductor is looking at a greater sum from all the individuals together. Which means: is the music coming out well? Is all the parts of the team is doing really good or not? So that’s their job. And the second job is to identify where the noise is coming, and try to fine tune it. So that’s where they are putting the second effort. As soon as you take the conductor out, the many times, if you see in orchestra, a general assumption is, what are they just doing? Why are they just moving the hands? Is it really required? But to come to that level, and for that orchestra performance to have a stand-up ovation, they would have practiced for at least few years. Takes like thousands of hours of practice. We are just seeing the final output there. We are not just seeing what has happened in the back. And apart from that, a lot of times, we humans tend to obviously make mistakes here and there. We create bugs in software. When we go back and see orchestra, the thing is that’s where this conductor is playing a wonderful role of watching around, seeing, “Hey, that’s where the noise is coming.” So you need to change it. And every time they do that. So they’re not redundant. First thing. So that’s not a bad model.

Let us take military. There’s a similarity that happens both places is they’re actually practicing. But in orchestra, when they go to the stage, there’s no difference between what’s happening in the stage, and what they practice. The only difference is that they’re seeing is audience. If you play a bad orchestra, probably they’ll throw something at you. But apart from that, the general assumption is there’s no chaos being introduced by the audience themselves. That’s guaranteed. But if you take a marine or like a military group, they’re practicing the same way that orchestra is practicing. Every day, they do the same drills. They are practicing or choreographing the same moves. They’re practicing how to shoot. Do things. But when they go to the field, things are not going to be same. So what they are going to do is they’re going to try to think about all the possible options in which this team is going to be disintegrated, and also see all the possible options in which you will be injured, and how to get back safe, but also finish the mission. So those two are like really interesting points. There’re lot of other parallels I have, like this parallel is really good, because in military, they’re trying with always having that thing in mind that, okay, even if I do all this practice, still there is some edge cases, which I don’t know. Because people play strategies. And that’s how organizations work.

Say, you have the best team with yourself. And then you formed a very, very… We know like wonderful startups that are formed with wonderful founders. And they have the world’s best ever code written. And they have the best UI, that they all built. With all those things, they still fail. Because they are part of a really small system. And they don’t know how it works. And all those things. So at a grand scale of things, you can also see a lot of companies when they were like very small, they are very good, but as they start expanding, the same chaos get added. Because you don’t know, like as soon as one person joins, what chaos they introduce or like what changes. So everybody introduced get some entropy to the system. And that entropy cause some noise. As the noise increases, you need to create, add a conductor at some level to keep on watching the noise. So I cannot generalize saying that, cause the same example I said, orchestration there, and then orchestration in an borough versus in military, they’re all different things. We cannot take something in one company and then applied that. But what we can do is we can find patterns and then do it. For example, if you go to Japan, and then you see other company doing this, and then trying to learn from their improvements, you can definitely do that. That’s absolutely fine. But if you take that same thing, I think this is what a lot of people do and go wrong. There is a successful US company, for example. They want to set up company in India. Many times, I have seen a lot of examples. They come in. They do the hiring in the same way they do it there. And then they do set up the management structure in the same way it is done there. In fact, they also give a lot of benefits here, and put all these fancy places, fancy everything. Give you like rock solid salaries. But if you see the throughput, it comes really, really bad. So there are two things that we can think. One is “Hey, US people are like a lot more efficient than the Indian team.” Maybe are they scale of things? I don’t know, because whom you hired is up to you. But when you again, take up the same teams, and then put them together in one room like, say, if you form a team with five people from US, five people from India, and then perform. Probably it works well, right? Like you never see too much deviation. So why is that working? But why is this not working? This one is failing. I’ve seen people who burned like a million, and then start, set up, do all those things, and then close it off after that. And say, “Hey, the problem of this is, managing this is too much operational overhead.” So they ended up closing up those offices.

So the learning there is you can’t just copy the same thing. Systems at scale. So you can’t say that this, I got 10X. I can get like 20X by doing this. Nope. You need to understand the local culture and do what is exactly right for that. And one important thing there is you need to find an amazing local leader. A lot of times you find that one leader, there’ll be like a considerable amount of difference. And they bring in a lot of other leaders, or they grow a lot of leaders, and automatically the whole organization improves a lot. I did not give you an exact answer, but my general answer is you have to work both local and global scale, and that’s how it scales. And we can’t take these and also directly apply, but we can take those patterns of improvement and do things like that.

What Makes a Good Manager/Leader [00:36:40]

Henry Suryawirawan: [00:36:40] So I like when you mentioned that one of the conductor’s task is actually to find out noise and fine tune the output of the individuals probably, or the parts of the systems to actually fine tune them, maybe repair or maybe just align back to what they’re supposed to do in order to produce a unified output. So I think this is also a good parallel for the role of managers, or managers of managers. You have a chain of managers within a company. But oftentimes I think fine tuning this noise is not easy. There are communication problem, like what you mentioned. And also the trust problem. So in your opinion, what does it take to be a good conductor or to be a good manager in that sense?

Ranganathan Balashanmugam: [00:37:18] It’s an interesting question. So they’re talking about two things here. A lot of times there are managers. And there are like leaders. And there are people who are a good leaders and managers. So many times, what is the role of a manager? The role of the manager is to find out things and then make it more efficient. In the case of, again, sticking back to orchestra, if it is a manager, the manager will get more throughput from individuals, and make it more efficient. “Hey, can we make more shows by doing this? Can we make it more efficient? Can you do practice more?” You apply this technique and this improves. But if you just move from little bit outside from there, and then if you assume that they’re just a leader. Then the leader says, I want good music. There is a direction in which I’m moving. And this music is good for a lot of people. And it takes us in a positive direction. So let us all do good music. And they’re just standing and watching. They’re just giving you a direction and setting you apart. That’s it. Now take a person who is a leader and a manager. So that person sets up the direction saying that, “Hey, the music that we are all producing right now is really bad. That’s not even close to what we are trying to reach. And we all can agree that we are amazing. We don’t have any problem with our talent.” So the skills, there’s no issue. Maybe there’s a motivation issue? So they work at that layer and try to understand. I’ll expand on that more. But understanding not only just the direction, but also improving the total performance of the team at different levels is important. So let us take managers at different levels. When I say managers, let us use the word leaders. When I’m saying leaders, they are also good managers. So they take a very, very juniorish manager. The first thing is obviously their motivation levels are really high, because they’re very enthusiastic about the new job and all those things. And they start picking up different tasks, and try to get things done. And so they’re also learning that role. Which means they’re like as anxious as the team is also anxious. And sometimes when you’re promoted within the same organization, one of the peers whom you are like, just having a simple conversation becomes a little bit different, because they start thinking, “Hey, are you talking as a friend or are you talking as the manager?” So there are multiple roles. There are a lot of things that we can go in detail, but I don’t want to go really in detail. But I like to make it more abstract or encapsulated, let us keep it simple.

When you started as a manager and then you progress as a leader, there are three things that happens. In the beginning, you’re just focusing at the techniques level. That is the level at which you are working. The second level when I see, so all these are like my opinion, I don’t say it’s not. This doesn’t have any scientific proof. So you have to take it to that task. So first, a set of managers will set off a couple of years, very junior, but they’re like looking at a technique level, like, move this, change this, do this, this’ll happen. And they’ll see improvements because it’s at a technique level. The second set of managers, they are leaders. They work at a level of changing the form, which means they work at the people core level, understanding them, trying to make them improve at that core level and enable them to become better. So when they start doing that, then automatically the performance and other things improves at a different stage. So that’s other stage of leaders. Then I see really excellent ones, who are like they work at a psychological level, I can say. So they set up dreams, but they are not like just stopping there. They have an exact clarity on the direction, and they also motivate and take people to that level. These are the people who can just take really underperforming team, make some modification, move people around. They move people, add people, but finally they will get them to a level that you will not have imagined. They’ll get a 10X productivity or something like that. But also people are happy. Managers can keep the productivity on, but still people are not happy. But these people are like at a different level, where not only making you very productive, but you’re happy and very much motivated, and you’re feeling it as a group. So when you said, who are a good leader, I would say, this is a journey that most people take. And it’s very hard also to start directly at psychological level. These things get through some experience.

Henry Suryawirawan: [00:40:32] What do you think are some of those attributes or those core skills of such inspirational or psychological leaders, you call them? So what are some of the skills that they have? I’ve experienced some of those leaders in my career as well. Vision obviously is one thing. But vision without proper guidance or direction, is also not working. In the sense that, coming back to your manager versus leader analogy there. So, what do you think are some of these, maybe attributes or maybe core skills that they have, or maybe some psychological expertise that they have? What makes them such a more impactful leader?

Ranganathan Balashanmugam: [00:41:03] Let us take some good examples of people. So again, obviously I didn’t work with them, but let us take Walt Disney. So one of the things that you would observe Walt Disney is the dream is really big, very, very big. They’re not just talking, but they know their stuff really, really well at a very, very core level. They know most of the things. They know the trends. They know what’s coming up, but they’re like top notch leaders in their own industry. And that gives them an unfair advantage compared to a lot of other leaders that you get. Like you can’t hire somebody else who is from the outside industry, rock solid leader, and put them…, I guess top sports manager cannot come into Walt Disney’s place in Disney and then change Disney. That won’t happen. So what happens is these people, one of the things that I see… Let us take again two examples, like Steve Jobs, for example, or like let us take Indra Nooyi. Also, there are a lot of leaders whom we can look up to. But one thing that you see common across these leaders at that level, when we’re talking to them, like really, really very good level. They’re all working at different scale of understanding. Their actual expertise is very, very deep. They know their cores. Their core strengths are very, very strong. There are very few things they may not know, but they’re always anxious learning things. So they’re always giving themselves ahead.

The second thing is they have like very good way of expressing the concept like back to us. So this is the dream. A lot of people have dreams. And then you can come and tell somebody saying that I want to build a company which has a lot better movies than Disney. But the point is you can’t just be very abstract on that. You need to understand that at a very core level. So that’s one thing that I said. The second one is they are very good at delegation. So lot of people I work with. These are people again, I’m not just comparing because. I didn’t obviously work with Steve. But lot of really respectful leaders I’ve worked with, they have very good delegation framework. So they give you direction and they also give you all the freedom within the framework saying that, this is something that you have to do, but this is within this framework. So I learned it from a very good leader I’ve worked with. His name is called Craig Fulton. He was amazing in this thing. He used to really give me the direction, but the delegation was very clear at the norm. So this is the budget that you have, you can’t cross this budget. This is the timeline that you have. These are the end points that you can do. The accountability boundaries were also very clear. They set things up very clearly by doing delegation. So delegation is not a very easy task.

The third thing, they have very good teams. Of course you can’t have a very bad team. Or like at least the team that they work with are all working through that. They are like part of the same orchestra. They are not creating so much noise. So with that again, it’s very hard to work. If they find noise, they’ll again obviously remove the noise and bring in the right people to make that music proper.

EverestEngineering [00:43:12]

Henry Suryawirawan: [00:43:13] So let’s go back to your company, EverestEngineering. So you founded this company, came up from your, so-called inspirational journey at Mount Everest. What is so different about EverestEngineering? Maybe you can tell us about the culture. What kind of a leadership that you show there inside the company?

Ranganathan Balashanmugam: [00:43:28] I’ll give you a scale on which we are working right now, so that people have an idea on what scale we’re working. So we’re not like really big. Exactly in four days, we’re like two years. Just before COVID, we were like around less than 1.5 year. And we went from one employee to around 75 people. That was in three cities. One is in Bangaluru. Other one is Hyderabad. The other one is in Australia, Melbourne. Right now, after COVID we slowed down our hiring, but eventually we started again. So right now we are 80 plus people. And still we are scaling right now. So that’s the scale on which we are working.

What’s very unique about it is, so initially when we started, I was all alone at that point. One thing I thought was: I really love making software engineering better. And I really wanted to just see things as problems and then solve them using software. One thing I saw across the globe was a lot of people are moving towards, especially on the tech side, on exciting technologies. Haskell came in. Okay, let us do it in Haskell. Hey, Golang is cool. Let us do it in Golang. But a lot of times, they’re not understanding the implications of it. I don’t say that’s bad. But are you using it as a right tool for right thing? Say if you want to travel within the city, you don’t use airplanes, right? I have seen people doing that. Just because of Hadoop was cool. I saw people at that time using Hadoop for storing really small databases, which a simple Postgres can handle, like a very, very small instance of Postgres can handle it. And usually they go into that maintenance nightmare. And they struggle maintaining the cluster, hiring more people, which is more burden. Which means a lot of aspects of software engineering that are very, very simple. And can we improve the software engineering by building a team around me? It can be a product or something. So that’s why I started. Actually, I didn’t have like a very clear vision of should I be in services or product. And I didn’t also have any product ideas. So that was when I was one.

But even I felt like, okay, let us work with people, get them together and then see how it works. So that’s where we got in more people. And got another co-founder called Craig Brown. So he’s very good at collaboration. So started learning things from him also. Eventually we started forming smaller teams and bigger things. But one thing that stayed common from day one till now is we always believe we ought to do better software engineering. But software engineering, again, it’s interesting because there are trade offs always. Any decision that we take, there’s always trade offs. Different customers come with different problem statements. And you cannot apply all the best practices of software engineering at any particular time. As a developer, I can’t compromise on quality. But I can compromise on few things. They want to build it in a smaller system? Fine. Do you want to do it with this limitations? Fine. You have a budget issue? Fine. But other core things like, “Can you write a simple dirty script to run this and, within one month, whatever it takes, just write that code, but I want this to be done.” Probably we don’t connect at all, like in the company within ourselves. Like when you go and tell them, “Can we do this?” No. But everybody is aligned towards. We don’t do TDD probably. Because we want to do TDD, but always you can’t do that. But can we do like unit testing first and then probably like industry driven. Or like almost in 99 % of the time, we always follow DevOps. The first thing that we do is make everything automated and put DevOps in place.

So coming back on that. And again, one more thing that a lot of people ignore is design. Initially when we formed the company, there’re like around 10-20 people who worked on projects, we used to produce really good code. But, we were working a lot of times with the founders of few smaller startups, and the thing that we found was we produced very good engineering, but there are a lot of UI was really bad. So the user behaviors are not very good. So then we brought in designers. And that’s when we found we’re producing very good engines, but not only just the aesthetics, the usability was very bad. When designers came in and then we merged the designers directly to the teams, so they’re very, very low level. Then we start producing better cars or better bikes that I can say. It does better usability, better things. But again, with the limitations of the budget of the customers and other things. So that’s one thing that where we all connected. We produce better software engineering quality with some of the core principles. So that’s one thing. The second thing is accountability. So we don’t compromise on accountability. People have like a lot of freedom. It works like a city, right. We thought of make it as a community. So from the beginning, even before COVID, we are like remote first, which means you can choose to be remote like anytime. But to be remote, these are like the guidelines. You can’t skip that. You can’t say that I have too many power cuts and I don’t have a power backup. No, you can’t do that.

Ensuring Good Engineering Quality [00:47:08]

Henry Suryawirawan: [00:47:08] So you mentioned quality first, so good software engineering practices first. Especially within the remote setup, how do you ensure that such a good qualities adhere to by everyone in the company right in the team?

Ranganathan Balashanmugam: [00:47:20] So first thing is hiring itself. When you hire, you can’t hire somebody who writes very, very bad code. Let us talk a little bit about hiring. So there are three dimensions in hiring. One is the skillset. The second one is the exposure of the companies they work with. And the third one is motivation. So first thing, what are the existing skill sets that they have, within the limited context of the companies that they work with. So you have to see both of them together. Some people are really extremely motivated. If you put in a scale of 1 to 10, their motivations are very, very high. For example, if you take a company that, all of technical architecture, everything will be done by one person. And you are just allowed to only execute on the cards. You are not supposed to view your opinions, or you’re not supposed to learn bigger things. So you are seen at that level. How do you know they have a lot of motivation? They always, within that constraints, they write very beautiful code. So they write unit test properly. They follow DevOps as much as possible when they do stuff. They automate things. There are like some factors on which you can measure motivation. And you know, that they are very, very motivated. And they try to keep on learning things. And when you ask, “Do you Dockerize?” “Obviously, yeah.” Making sure that whatever works in my machine works everywhere else.

So those are like some basic fundamentals, which even if any company restricts you at some level, you can do it for yourself. Then you know that their motivations are really high. But their skill sets are limited by the existing company, so they’re not able to learn or go beyond that. Then if you balance that, you get a very good hire. But you also get other kinds of people. They are balanced on both motivation and their existing skillsets. As soon as you give them a coding challenge, or try to see their code, or give them a system design, they’re really good. Then you’re like, “Yeah, this is the right person.” That’s very easy because you know that the onboarding time will be less. But as I told you in the beginning, the onboarding time, you need to give balance for them. Like some people are like more motivation, so you have to fit in their motivation to come to that level and then match them with other people who are like really already there. And then go to the next level.

So first thing, we started with hiring and making sure that is not compromised so much. And obviously when you do a hire, you also make some mistakes. So there’s some misfires. So then you try to course correct it. You tell them like clear goals. We spoke about radical candor. And you have to tell them like, “Hey, I really care for you, but this is what I’m facing.” And many times, it’ll be mistake from our side. Like sometimes when I learned that, “Hey, this is a very simple thing I didn’t learn from you. And I didn’t give you that flexibility. And that’s why you are very slow.” Okay, fine. Take this thing off. Or maybe they’re going through some personal, really some personal problem. And there is some release. So they are trying to manage and they’re like struggling. Then that’s where we talked, spoke right, at a psychological. And you’re like really connected. And all of them, like give them that space. They’re humans. They’re not machines. Once you give them the feedback, and try to understand what’s they’re going through, and then try to help them. But even after doing that, sometimes it won’t happen. Like they may be really good or exceptional engineers, but they may not gel with the team. So they come in, and the hard part where I faced at many companies was they’re really smart and they pull through 80% of the load. And just because of them, the whole team is under performing, because they don’t give up to other people. Now at that point, you have to take a call that even if this 80% goes away, I have to give them feedback and make sure it is happening, or just let them go. That’s what is firing, which is extremely hard to do if you’ve not fired much people. But first, assume that it’s your mistake. Correct it. Then understand what’s problem from their side. Improve it. Give them time. But even after multiple times, they’re not progressing. Then the only thing that is left is firing. So also try to help them after firing, to find their jobs. Don’t be too rude. So that’s the second thing. Like again, as I said, helping them is also a part of software engineering is what I feel. We are all human. Software engineering is not something very different from us. Now the third thing is setting up the direction or like the problem statement. Different people like different problem statements. So first thing is how much freedom can you give people to pick up their problem statements? If you hire somebody with a particularly very good talent for something, and they’re like very much motivated, they are learning things, and then don’t put them there at all, they will not stay. You need to give them the problem statement that they like. And then allow them to do it in that way. So that’s the third thing like aligning them to the right problem statement as much as possible. So you can’t do it 100% of the time, but we at least put right effort to align that.

You have to be both a manager and also a leader. So you have to put your manager hat, and see what are the places I can improve things. A simple example. This happens all the time. You plan a sprint. And in the sprint, people ignore testers, most of the time during estimations. People ignore designers. So when you do that, obviously at the end of the sprint, you don’t have the next set of designs for the next sprint. That is much ignored. It should be actually in this sprint. All the cards will be in. Most of the cards, not all the cards. All the cards that you picked up can be tested only after one week or something like that. Then you are piling up the load. And if the developer velocity is too high, then obviously there’s so much amount of waste driven, because the tester gets overloaded, they have to work on the weekends. And even if they work Monday or Tuesday, the demo won’t happen because testing was not done. If you allow developers to put code more, then there’s more waste getting produced. I think that’s where you have to put your manager hat. That’s what bad things can happen. Test in your software engineering. So then you have to watch that behaviors. And try to keep on fine tuning it. A lot of times, quality, it’s not about just solving the problem. Quality is more about… even not making the problem to come to the surface. So you’re stopping it even before. I think that’s where managers keep need to put that hat and keep on finding patterns that is not repeating. And again, if your pattern is repeating for three or four times, then you’re actually not diagnosing the problem, but you are working at a surface level. You’re just cleaning up the wounds, but you’re not actually solving the problem. So you again go deep, and try to eliminate the dust. If you’re just wiping every day, and seeing dust coming in, there are some other source of dust. So you have to close the windows. Then obviously the dust won’t come. So you have to always trying to diagnose and find the root cause, not cure symptoms.

3 Tech Lead Wisdom [00:52:26]

Henry Suryawirawan: [00:52:27] So Ranga, it’s been a pleasure talking about all these concept. Collaboration, some of the abstract things that you can learn from different parallels. So we also learn about the manager versus leader, which I learned a lot. And the last thing, the last question that I have as usual in this show is that, I would like to know the 3 technical leadership wisdom that you would want to share with all of us, the audience here.

Ranganathan Balashanmugam: [00:52:48] Oh, okay. That’s quite interesting. So I’d like to tell, a couple of them. The first thing is leadership is more about a verb rather than a noun. You can’t just think that it’s a title thing. It’s an action thing. It’s not a title thing. So you can still be a simple designation like software engineer, but in the team when you’re working, people know that you are the leader. It’s very simple. When there’s a problem, everybody’s looking at you. They’re not looking around. So then you are automatically a leader. Then you do not have that noun. You’re still at a verb level. So that’s very important and interesting thing that I learned.

The second thing is it’s completely okay to be wrong as leaders. So don’t let the fear of experimentation, or like being wrong, like failure. So it’s okay to be wrong. Just be bold. And then, try to do things. And then experiment. But make sure, like at least measure the blast radius before doing some experiments, and put it in a safe place for all of us, because you are not alone. That’s also important.

And third thing that I generally felt was it’s okay to be irrational. Like lot of times, people have that intuition. Intuition comes with experience. You can’t come and tell somebody that, “See, this is what happens.” Many times, just before the demo, some people do commits. And they run the build. Mostly, if you go and see, in the end, people who are like more experienced, they never do that. They’ll stop it just one day before. Just for the demos. Even if it’s a simple internal demo, they stop it. They will not allow this thing to happen. They’ll say this is what we agreed on. It’s fine. There’s overflow. We couldn’t do it. But we can’t do this. But when I see like, mostly junior-ish people, they come with that enthusiasm that, “Hey, I want to show more features in this demo.” And they push it till the last moment. And every time, the demo fails. If anybody wants to give a rational argument, that is extremely hard. The same thing is estimations. There’s this concept of Dunning-Kruger effect, where people who are like less experienced think that their estimations are like more right. So, these are all like irrational, right? When you come and have this discussion with the engineers who are like really smart. They’ll say, “Hey, try the previous build. Do that. Do this.” But a lot of times, there’re like minor things that will fail. It’s okay to be irrational, and then allow people to be irrational sometimes, but not for always. Like you cannot say that, “I’ll write irrational code.” That’s not accepted. So code is obviously to be executed. So that’s the third thing that I want to talk about.

Henry Suryawirawan: [00:54:42] All right. So thanks again, Ranga, for your sharing the 3 technical leadership wisdom. If people want to connect with you online, where can they find you?

Ranganathan Balashanmugam: [00:54:50] Definitely LinkedIn. So I know that my name is really hard. If you’re not in India to pronounce search, but obviously in the comments or somewhere you can search. My name is Ranganathan Balashanmugam. You can search. Or you can just search for EverestEngineering, which is easier. And my name pops up. Definitely good to connect. And send a message on LinkedIn and I’ll be in touch.

Henry Suryawirawan: [00:55:06] Yeah, I’ll be surely putting that on the show notes. I mean like you are not alone. My surname also kind of long and difficult to pronounce. So thanks again for your time, Ranga. It’s good to chat with you. And I wish you good luck with EverestEngineering. And hopefully to see you again in some other events.

Ranganathan Balashanmugam: [00:55:22] Thank you so much, Henry. It was nice talking to you. And I really appreciate the questions that you asked.

– End –