#19 - Scaling Collaboration Across the Globe - Ranganathan Balashanmugam - podcast episode cover

#19 - Scaling Collaboration Across the Globe - Ranganathan Balashanmugam

Dec 14, 202056 minEp. 19
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

“With machines, you know there are limitations. You can’t go beyond that. You have to upgrade your machines. Or the technology changes. 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."

Ranganathan Balashanmugam is the co-founder and CTO of EverestEngineering. He is passionate about scaling and leading distributed teams, where most of us can relate to with the remote working becoming a norm nowadays. I had a pleasant conversation with him in this episode to discuss many strategies and thought leadership on how to lead a distributed team by taking parallel from distributed system, overcoming challenges of building a team with different culture, and how to nurture a team. We started with him sharing his career journey and interesting story of him conquering the Mount Everest Base Camp, where he gained some insights and inspiration throughout the trek. Ranga then shared what led him to take his first management role and developed strategies around scaling distribution teams over the years. We then discussed about hiring and onboarding, the concept of orchestration vs choreography when managing a team, and the qualities of an excellent leader. At the end, Ranga also shared about EverestEngineering and its differentiators to ensure good engineering quality for their clients.

Listen out for:

  • Ranganathan’s career journey - [00:06:16]
  • Trip to Mount Everest - [00:08:19]
  • How Ranga took management role - [00:12:55]
  • Scaling distributed teams - [00:14:43]
  • Onboarding new joiner - [00:26:23]
  • Orchestration vs choreography - [00:31:01]
  • What makes a good manager/leader - [00:36:41]
  • EverestEngineering - [00:43:13]
  • Ensuring good engineering quality - [00:47:09]
  • Ranga’s 3 Tech Lead Wisdom - [00:52:27]

_____

Ranganathan Balashanmugam’s Bio
Ranga has worked with globally distributed teams for the last fifteen years. He graduated as a civil engineer and became a developer for nearly eleven years. He worked on web, mobile, and distributed technologies to scale software. Later he picked up operations and engineering management at Aconex, where there were teams distributed in four different time zones.

He is currently co-founder and CTO of EverestEngineering, which he scaled the organization to 80+ people in the last two years, in three other regions. He is passionate about scaling and leading distributed teams.

  • Microsoft MVP for Data Platform - 2016, 2017.
  • Experience in building two startups.
  • Speaker at many international conferences and meetups
  • Experience in building distributed high-performance teams and offices.
  • Organizer of one of the top technology meetups - Hyderabad Scalability Meetup.

Follow Ranga:

Follow EverestEngineering:


Like this episode?
Subscribe on your favorite podcast app and submit your feedback.
Follow @techleadjournal on LinkedIn, Twitter, and Instagram.
Pledge your support by becoming a patron.
For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/19.

Transcript

A quick reminder. Before we start our episode today, to celebrate the end of 2020 and the upcoming Tech lead Journal. 20th episode. I'm currently running a giveaway contest for you to win jetbrains. All products pack, personal licenses for free. The all products pack license is worth two hundred forty nine US dollar and it allows you to use all jetbrains IDs such as IntelliJ. Pycharm Golan webstorm and many others. I will.

Choose five lucky winners and the contest will end on 20th, December 2020. All you need to do is subscribe to the technology on our mailing list. On the technology know that website and remember that you need to confirm your subscription by verifying. Your email address, in order to be eligible for this giveaway. For more information on how to participate and how to get additional bonus chances. Please check out the website at technology. You know that Dev slash.

Here's the link one more time package. You know, that death / giveaway. Please make sure to participate and special. Thanks to jetbrains for sponsoring this giveaway with machines, you know, the limitations you can't go beyond that beard upgrade your machines or like the technology changes, but with people in distinct Parts it if you get all the parts write the sum of the parts will be definitely greater than adding them together. Hey everyone. My name is Henry.

Sorry. 01. And you're listening to the tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello, my friend. Thanks for tuning in. Welcome to another episode of the tekhelet journal with me.

Ojos, Henry Surya. We are one 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. Polity, contents and stories from amazing.

Guess that I could invite to the show, in order to be able to continue inviting more amazing guest. 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 post interactions and comments would definitely helped me a lot to amplify the impact of my amazing guest. And if you are a fan of this podcast, I would like to make a

contribution to the show. You can go to the patron page at Tech, Legion of the death, / Patron and pledge, your support as a patron. I'm currently running a goal on the patreon page and any contribution from you with tremendously helped me towards achieving that goal. In today's episode. I had a pleasant conversation with ranganathan ballast on mugham or ranga for short ranga is the co-founder and CTO of avarice engineering a company that provides software. Cheering 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. In parallel 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 Everest engineering. 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 podcast and other podcast apps that allow you to do.

So those ratings and Reviews are one of the best ways to get these podcasts 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 technology, know that death, / feedback. So let's get this episode started. Hello, welcome to another episode of the technology. You know, today I have with me ranganathan Burleson, mugam.

I hope I pronounce the name correctly, or maybe I'll shoot prefer calling your name ranga. Saranga is someone I know from colleague of mine. I actually saw a ranganathan stalk in Yukon, 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 the 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 the distributed manner in a scalable manner. So that we all can work in producing things in a good quality. So welcome. Rhonda to the show and looking forward to the chat with you today. Thank you so much. Henry has been great listening to your podcast and being part of it is still awesome oranga, maybe before we talk about all

these scalable distributed team. You can maybe share with us your career Journey, so So what are your highlights or maybe major turning points? So I was actually graduated as a civil engineer and in my final year project that we mostly focused on picking up some interesting stuff on a and applied it back. During those days. There was not much internet here.

And I basically what are in use a book from somewhere and try to Again, by some C++ book because some of the code was in C++ and tried learning it myself during my college and try to apply that back in learning some models on a two-way, slab design. And that's where my journey for. Transitioning back into computer science. Begin and eventually started liking it and through campus. I moved it to a different path

that is society. And that's how I started becoming a software engineer from there. Like, it was around 12 years from, then most continues lot of programming, design and architecture of stuff. And the last thing that I was doing was mostly into working or learning a lot of distributed systems. And that was quite interesting for me because suddenly when we added more systems, the capacitor is increasing.

And the lot of other Technologies like Hadoop Kafka sparkling 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 20 years. I'm took complete transition into in management. Come an operational role. So moody a company called a Kleenex that's where I started managing multiple engineering teams advance. And that was that 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. Urkel. And from there I moved to and started actually complete called a reverse engineering. So I took a break and went for a one month. Actually two-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 why our whole ever seeing started. I'm contouring here SC2. 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 uninterested. When you say that you went to Base camp took a break and basically try to find out what to do next. So maybe you can share that kind of 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 address so many public company? Like Oracle buys another company like a techniques, which is another public company. One of the things is it's super busy activity because there's a lot of playbooks that the company starts executing and it was three different time zones because I was in India and

Oracle Headquarters was in u.s. Oh and techniques was President Melbourne, which is in Australia, which means early morning, we start most of the work and we also have to think about back during afternoon during the Indian time and then a lot of calls in the night to match up the US team where that used to be super, super busy for nine months and the whole transition was happening. So the point was not able to make a clear Russian 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 soap in one week. I just decided to book the tickets and went to Kathmandu and from there went to Everest Base Camp. A lot of interesting things that you can do there. One, most important thing is we don't have a laptop and moves at least 99 percent 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 for 30, something like that every day, you don't have a chance to go out much, you Chrome around but you're like most constrained within the space because it's too cold and more higher. You go it. Smoke older 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 a like a small wooden place and your two options when it's like there's a common all everywhere where you go and you chat with lot of people and then learn from them and there are interesting things there or you just sit in the room and then just think for yourself without mobile with our laptop. No TV nothing. So that's a beautiful time to

think for a lot of things there. Like, 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 go very fast for 23 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 back to companies or your team's.

A simple thing is, if you go to a higher altitude your body needs more oxygen from the air or like the equal toxin that you need normally but from the thin air. So the air becomes more thinner because of that our body needs time to change its cells to create more red blood cells with that. You have like more capacity to absorb the oxygen and Moorhead. So you need to Your body that time. I'll tell you they're like an

interesting thing that happened. So there are a couple of people who are like really rushing forward and the few people in our group selfie. You should not be rushing for

words. You should slow down and all, but ignored, but after one day, we saw them lying down on the ground because they couldn't support dogs in that was needed because your brain needs time to produce that the alternative is you take capsules which produce more often, 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 account as yourself and learn things, and I always apply that back to earning more like

onboarding your company. You can't hire a person who is really smart and then think that, hey, they'll come into your company and start or performing 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 has different styles and that's interesting because you come back and learn with that.

That's our onboarding. And same thing that I try to learn from them and there are 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 start much a lot of the luxuries that you have or limited for yourself. When you come back the first box that you take. That's a big, big luxury. Yeah.

So I think these are some of the interesting things that I have like the lot of interesting things, but it's an experience, you have to actually go there and experience it and one and only advice I have is real trashy. Enjoy the pool journey and then come back. There is no point in going there and then racing to reach the top. Yeah, I can sense the like, for example, you go into this tough environment.

Let's take an example. Like you go into this big companies 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 FRS 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 this kind of moments as well when I go for a walk every evening. So sometimes you have these kind of inspiration, somehow going through your mind. You have also another interesting story, which I quoted from the top 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? Yeah. So I started recording like around 16, 17 years back and interesting part at that point is you have very minimal memory and then you hold like very minimal power. At the point. When you write a code. You don't need the whole, like, a simple mission in training takes a couple of days. So your mission is just running. And if there is a power cut, the whole thing is gone. Your to restart it, that's very interesting.

And from there once I started seeing things that 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 and Paul interesting topics on scaling and I also used to learn a lot about that, one of the directors of Economics. He called me when I was in the previous companies a developer initially the conversation started as an engineering manager, but you enjoyed it more to get off doing other things. The That he told was very, very interesting which convinced me to move?

One of the things that he said was here. And whenever you speak, you're showing a lot of excitement about scale. And the most interesting part here is a lot of things that you learn from scaling systems. Horizontally can be applied back to people, then I said, do you think the system and people are saying then he said it's not like that but you can definitely learn from Palace. 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 meant for at least, 30, 40 minutes. Then I played on some of the examples from here and then he gives some counters examples on that side. One is on the engineering side and the research 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. There is also like quite interesting, but it's more challenging because people are more complicated. 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 line much

stronger. And I know there are obvious 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. Let us take a simple thing like a God, if you take a car 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 the Our second thing is, if you want to buy the most, most powerful bull than it's the most expensive thing in the world and you by heat and then keep it, but it also has limitations. So the other smart idea is to put two bulls and then add to the car, and that's how it scales and then start pulling it. So that's where, like, we move from a processor in tumult ecosystem. But even for multi-core system, it's again, a single card.

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 blue cards. So that's where you had to The cards and then try to pull the load or distribute the load across cards, horizontally. How do we scale machine? Similarly?

Can we use a single system or can we like 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 had 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 they're coordinating, which means there's an intense amount of organizing and coordination that needs to take place across

people. And that's Are you need proper management and Leadership to to 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 mood, when management thing become with the mindset saying that he now I have a problem. This is solved by five machines, in fiies can increase the throughput of doubling my machines 10 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 paper. Collaborate, which is some of the machines work is different. Machines are just following the protocols. People don't follow protocols and 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 that throughput.

But if you're managing, well, probably you get 10 times, the throughput that's more interesting because with machines, you know, the 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 distinct Parts it, if you get all the parts write the sum of the parts will be definitely greater than adding them. Together.

Yeah, what do you think are some of these Hearts When you mention like what things that make these kind of collaboration between people can be more than the sum of its parts Village 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 he explains is very interesting because that's 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 Don't even the exact words that we generally use for it. But I think it's physical distance, operation 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 this actual physical distance, you can't collaborate that

easily and it grows, right? Like your between officers to different time zones and eventually, even within the same company, even if the co-located, if you are from a different organization on your like insulting versus actual employee, there is some distance for not really connecting at that core level. So that's what is the physical distance? The second one is Is operational distance operating 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 videos 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, for trust. So these are some of the things that will come in this way. And a lot of work is done in this place and different companies have different strains of things. Let us take an example of trust people. All the options that you want to go on at, what level do you you at least most of the people, I talked 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 is an expectation Gap. And how do you clear? That Gap is By giving more clarity, and how do you create that? Clarity is giving them Norms? How do you create Norms? A good example of, that would be cities. So let us take cities and if you're, for example, I'm in Bangalore and then I discovered and didn't know much your rules

about the city. Basically, you can't kill people, but apart from that, there are basic rules, which can be cannot break as humans. But apart from that, you are allowed to take your own dacians and Moorhead show. See your own 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 I should behave in Singapore. I look around and as soon as I see people, I know that, hey, this South buses work in India

and these. So people go in buses in Singapore and probably by seeing those behaviors and trying to understand and learn from his when you start learning about it. Other than 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. 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 studied in before paying and then, Then while eating I just gave my card and they said no cards. So interesting part is, you actually 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 now destiny put out and I had to have that conversation to get it done. But the thing is very simple. That's what we are talking about

the virtual distance. So this is a very small part of virtual distance. We are talking about Freedom, accountability the framework for 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. It's too crowded in India. You can just skip the line and then go across people. Do few things, but you cannot do that in few other cities for

exam. 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 a 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 value of impact of that when you apply it back to a company's 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 in office in India. So actually one of the things that you see is people are brought up more independently. So the to take more independent decisions and kind of authority to nurse is lot less. Now, if you take Japan for example, and if your work with Japanese people, it's very authoritative culture.

So, the way people sit versus the people take decisions these a lot more different than, again, if you take India, it's little bit heretical. But because they're working with lot of Gallatin companies. There's a confusion because some people try to apply it there and that Doesn't book. So these are the things where you can try to improve the virtual distance, which means there are some things which are very local to a particular culture, but they're 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 a radical organization and you're not giving onboarding time of a new culture. And then you suddenly say, we are all garroted in everybody. Take their own dacians. It becomes extremely hard. So that's where virtually since become very, very different.

And then, if an Austrian team, I'm Japanese team and indeed team of collaborating. It becomes extremely hard. You have to understand the virtual distance and then try to improve on that. Yeah. This is such an 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 said, authoritative as Independent, hierarchical Business, may be. No hierarchy.

So, these are some of the things that obviously, it's pretty abstract. So, how can you improve your visual distance for someone who is just joined a company? 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 are not working with a similar organization, even if they work with a similar organization to organization out or never exactly the same, this is definitely going to be a lot of difference. And each time a person gets added to an organization, the style changes. I'll give you another very interesting analogy, which I like.

So if you take boat racing Generally, the way people city, is there are like eight people who sit alternatively and they actually row the boat on a reverse Direction and they see the lead of the boat on the other direction and they watch for hints. These are the people who are like actually controlling the direction and giving you some of the ins, but the amount of practice that they take to make it more efficient. He's just to get all of them on

a similar case. 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 we are all coming to the same point? So I'll take another parallel so that they like some, my new distances which will be more clear than other pallor least.

Let us take an orchestra, which is a very, very good example for collaboration in an orchestra assume that you're bringing in a new person who is just doing to do drums. Now. If you don't give them the onboarding time on this Trail of the conductor, and other thing the hardpoint for them is the day one, you take. Um, the orchestra doesn't become grateful. It's not that easy. It's exactly similar to

companies. You cannot pull in people from other orchestras and put it in different orchestron. Think the music will be seen. It's very hard. And companies are exactly going to be same. As soon as an individual gets added, there is going to be small deviation. If you put it as a very minut graph. There is a change in culture. Every time you person gets added.

And as our mission scales, the cultural part keeps on changing and that's why you have to keep on working on the virtual distances, but in an orchestra conductor, which is very simple. So this 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 parallels. So you check around watching the behaviors and try to understand. Hey, then this person says moves his hand like that.

It means I did something wrong. I need to correct myself. The second thing is the MU little bit harder. It means you can't admit it. It's like a very hard one in so that part, you understand here, maybe in another group. They just watch you very seriously, and if you don't get that Q, it means that you're not understand. So that's the behavior understanding from different cultures. Now, assume that two different orchestras to work together. So that's how like organizations

are like working. There are so many orchestras happening and this be a marshal coordinator. That becomes extremely hard. So that's why you need to allow the orchestra to be local enough that a 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 Port. The same thing will not apply because in an orchestra versus both in rowing their eight people as soon as you change one person all the time, the person space will be different than all the other people because they are practicing a different vote when they do the rowing. Again. The interesting part is their base is going to be different and all the other seven people are going to change their pay is just for that one person.

And that's how the collaboration He's now just assume and apply the same rule back into in Orchestra. Assume that the person is playing drums, can all the whole organization Hall the whole Orchestra change, its tail to match. It pays for Tempo to Drums know, we can't. So which means one thing that's common at. Both the SEC, did observe the behavior and change it yourself, but there are like organizational principles and cultural commonest.

Very, 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 phase, then keep on improving. Continuously. 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 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? What we do, which was more efficient, was to bear and then also promote travel. So, first thing I'll talk about pairing people. So any news on Ava comes from a completely different culture. ER, 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 these how this works. This of this world. Say you need to do that. This how you do and all that part is really hard. Because right now we have 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 are there and how people behave their online and you watch people in the cause.

But apart from that we set up a lot of calls to onboard them into the system, give them some icebreakers and make them comfortable while Means 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 a different random people who will be like playing a plea most of time at least similar laws because they know what that kind of role expects and the whole way in each day looks like and one most interesting thing that at least I do whatever singing was even before releasing the offer, I'll just tell the household d looks like, so that they will, at least try to understand that this of my do. It looks like, is it exiting?

Not exciting. Should I join or not? People may not like the kind of expectation that we have on learning. It's fine. At least after joining taking the dish in as as you know, that this is expectation. That you have every week. You need to do this or learn this, they will know that. Okay? And committing to this and joining rather than, I don't know the space and joining. So it starts before joining. Of course, we do all the interviews, but after that, there is onboarding.

And after that allow people to mingle or pair up with a lot of people, Shadow and different people on different pages, so you should give them time to digest. We cannot say that by following this x process. All of them will be improved by like say from 15 days to 10 days. Won't happen. Maybe for a few people. It will be just 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 are sort process

perspective. So one interesting thing that I learned T is a lot of times we come from with this engineering mindset and if a company is dominated by a lot of Engineers, we try to think everything rationally, when you are rational all the time, it won't work like that, especially with people. So you have to apply some relation, which means you 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 a I'm right. Like you can't take a starting, put it in a different company in the expert. The star results. No, it won't happen. We are a 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 exemptions. So sometimes it's okay to be rational and allow them to absorb that and then learn that, that accommodation should be there like for accommodation you have pills.

You can take and take the 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 improvising them connecting with them. And then taking feedback from this also important because one of the Great Father, they have which we all don't have, will be a new pair of ice on which they will all start looking each other until one interesting

thing that I learned. So when we started Everest, initially the small and then few, we were all sitting the same table when we wanted to go and have tea or coffee. So, T 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 scale to like 20 conflict people. It is hard because all 20 people could not go at the same time. So we said, hey, can we move the

tee back here? And then we started ordering tea and every day at particular time you get, Marty didn't X2 times more the morning once. And then evening, then this class you take the T. Then we grew up to 40 people. Suddenly somebody came. And then like, at least we follow the habit of what is good for you. What can be improved, that's the feedback that we keep continuously. And when we ask 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 set in office. There's no coffee. Then, that's the first time. We realize that there's no coffee because we didn't have the fresh pair of eyes and every division that they only serve tea here or something like that, then instantly then, and there we make it shoot it from next. A coffee is there, we took a voting and then we His own people, drink coffee, how many people will drink tree. Then?

We started getting too fast. This may be simple example, but you can be applied at the organization level when you scale and see hundred things that you provide with this level. The same Japanese concept of Kaizen applies lot better. Yeah. I also learn 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. It's 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. Eli's. 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. 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 that a place for choreography in collaboration? We didn't scalable teams. Can you expand on? What could it really means? Just to be clear, the choreography? Orchestration. The defense. Yeah, so the orchestra normally is to 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 group performance. You have people who actually perform as what they think would make a beautiful than. 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. We as a group. So that part is interesting because I'll again, take another balance compared to that. So let us take a focused on versus military group.

So let me complete on the orchestration, part of a conductor and Orchestra. So, now to start the practice every day, but they know that from the new things comes from the conductor, which means conductor is not looking at any individuals 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 To find you need. So that's why they're putting the second effort. As soon. As you take the connector out many times. If you see an orchestra, a general exemption is, what are they just where they just moving the hands? Is it really required? But to come to that level and for that Orchestra performance to have stand-up Ovation, they would have practiced for at least few years, takes a

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 are not redundant first thing. So that's not a bad model. Let us take military. There is a similarity that happens. Both places are 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 that they are seeing is audience, if you play Bad, Orchestra, probably the throw something at you.

But apart from that, the Exemption is there is no chaos being introduced by the audience themselves, that's guaranteed. But if you take a marine or like a military group, they are practicing the same way that August respecting every day. They do the same drills. They are practicing or choreographing, Jesse moves, the parking, how to shoot do things. But when they go to the field, things are not going to be

saying. 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, Intermission. So those two are like really

interesting joins. The lot of other Palace I have like this palette is really good because in military, they 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 would 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 are built with all those things. The still fail because they're part of a really small system and they don't know how it works and all those things. So, a grand scale of things can also see a lot of companies then. They were like, very small, they are very good.

But the, as you start expanding the same curves, get added, because you don't know, like as soon as one person joins, what care of the introduced or like, what changes. So, everybody introduce gets some entropy to the system and that entropy cause some noise as the noise increases. You need to create ad and conductor at some level to keep on watching the noise. So, I cannot generalize saying that, because the same example, I said, orchestration there and

then Orchestration in anbu. Route, versus in military are all different things. We cannot take something in one company and an applied there. 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 another 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 on 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 rehiring in the same way. They do it there. Then they do set up the management structure in the same way. It is done there. In fact, they also give you a lot of benefits here and put all this fancy places and everything. Do 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 he u.s. People are like a lot more efficient than the Indian team, maybe at a 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 come home. Mom, probably it works. They'll write like, you never see too much TV. So why is that working?

But why is this not working? This one is failing. I've seen people who burn like a million and then start setup, do all those things and then close it off after that and said, hey, the problem of this is managing. This is too much, operational, overhead. So, they end 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 10 x, you can get, like,

20 x by doing this. No, 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 locally. 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 of the grow, lot of leaders. And ultimately, the whole our

mission is to serve. All I did not give you 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 endless also directly apply, but you can take those patterns of improvement and do things like that. So I like when you mention that one of the conductor's tasks is actually to find out noise and fine-tune the output of the individuals, probably or the parts of the systems to actually

find you. In 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 or the role of managers or managers of managers. You have a chain of managers within the company, but oftentimes, I think fine-tuning this noise. It's 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? It's an interesting question. So we're talking about two things. A lot of times, there are managers, and there are like leaders, and there are people who are 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 the leader, then the leader says I I

want good music. That is the direction in which I am 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. It's not even close to what we are trying to reach and we all can agree that you're amazing. We don't have any problem with our talent. So the skills there is no issue. Maybe there's a motivation issue. So they look at that layer and try to understand. I'll expand on that mode. 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 to manages. Let us use the word leaders when I'm saying leaders. They are also good managers. So we take a very, very Jewish manager. The first thing is, obviously, their motivation levels are really high because they are 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 are also learning the true. Which means they're like as anxious that 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 the simple connection becomes a little bit different because they start thinking, hey, are you talking as a friend, or are you talking? It is manager.

So there are multiple dogs 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 in caps ready to 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 Like my opinion, I don't say this.

Not, this doesn't have any scientific proof. So you have to take it with that task. So first a set of managers or set of a couple of years, very Junior, but they are like looking at a technique level, like, more these changes do this, this will happen and we'll see improvements because that's 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 at 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 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. The 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 remove people add people but finally they will get them to a level that you would not have imagined you get the 10x productivity or something like that.

But also people are happy. He managers can give you protected your own but still people are not happy, but these people are like a different level. We're not. Making you ready product? You but you are happy and Moody much motivated and you're feeling it as a group. So when you said go a good leader, I would say. This is a journey that most people take and is very hard. Also to start directly at psychological with these things, get through the experience.

What do you think? Are some of those attributes are those core skills of such inspirational or psychological leaders? You call them. So, 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, fascist leader analogy there.

So what do you think are some of these may be attributes or maybe core skills that they have or maybe some psychological expertise that they have what makes them such a more impactful leader benefit from good examples of people. So again, obviously didn't work with them. But let us take Walt Disney. So one of the things that you would observe with Walt Disney's, The Dream is really be very, very big. They are not just talking but they know their stuff really, really well.

That is very, very cool level. They know, most of the things, they know the Trends. They know what's coming up, but they are like top launch 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's from the outset Industries or a leader and put them against top. Sports manager, cannot come into Walt Disney's place in Disney and unchanged. 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, a greater stake in run. A, we also the lot of leaders whom we can look up to but one thing that you see common across these leaders are that level when we are talking about it, like really, really very good level. There are working a difference. Scale of understanding their actual expertise is very very deep. They know their course the quotient or very very strong.

There are very few things that may not know but they're always anxious learning things. So they're always giving

themselves. However, the second thing is they are like very good day of expressing the concept like back as so. These the dreams lot of people have twins and then you can come and tell somebody saying that I want to build a company which has a lot better movies and Disney, but the point is, you can't just be very abstract and that you need to understand that to be very cool level. So, that's one thing that I said, the second one is, they

are very good at delegations. Not of people, I work with these are people again, and not just comparing because I didn't obviously involved with Steve, but lot of really respectful leaders have 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 learnt it from the pretty

good leader. I cope with his name is called Craig Fulton. He was amazing in this thing. Be used to really give me the direction but the delegation was very clear that the norm. So it is the budget that you have. You can't cross this budget. This is the timeline that you have. These are the internships. Points that you can do the accountability boundaries are also very clear. They said, things are very clearly by doing delegation. So delegation is not a very easy task.

The third thing. They are very good teams. Of course, you can't have a very bad team or like, police the team that they work with are all working together. They are like part of the same Orchestra. They are not getting so much noise. So with that again, it's very hard to work. If they find noise. Well, again, obviously remove the noise and bring in the right people to make that music proper. So let's go back to your company FS engineering. So you founded.

This company came up from your so-called inspirational Journey at Mount Everest. What is so different about efforts, engineering? Maybe you can tell us about the culture, what kind of leadership that you show their inside the company, I'll do a scale on which we are working right now. So that people have an idea on what skill you're looking. So we're not like really big exactly in four days.

We are like two years just before covid-19 around less than one out of here and we went from one employee to around 75 people that was in three cities. One is in Bangalore, other one is Hyderabad. The other one is in Australia, Melbourne, right now. After copy. We slow down a hiring. But eventually we started again. So right now we are 80 plus people and still Till 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 the point. One thing. I thought was I really loved 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 existing Technologies Haskell came in. Okay, let us do it in Haskell. Hey go long is cool.

Let us do it in

but a lot of times they're not understanding the implications of it. I don't say that's bad, but are using it as a right tool for, right? See, if you want to Traverse within the city. You don't use airplanes, right? So I have seen people doing that just because of Hadoop or school.

I saw people at the time using Hadoop for storing really small databases, which a simple postgres can handle like a very, very small instance of persistent hundred and usually they go into that maintenance Nightmare and they struggle meeting the cluster hiring more people, which is were button, which means a lot of aspects of software engineering that are very, very simple. And can we improve the softening by building? A team around me, can be a

product or something. So that's why I started actually. Didn't have like a very clear vision of should I be in services or product and I didn't also have any product idea. So that was when I was one, but usually 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 call Craig ground. 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 State Common from day one till now is, we always believe you have to do better software engineering but software engineering again is interesting because there are trade-offs always any decision that Take is always trade-offs different customers come with different problem statements and you cannot apply all the best practices. Of course for changing at any

particular time as a developer. I can't compromise on quality, but I can compromise on few things. We 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 Iraq or things like, can you write a simple data script to run this and within one month, whatever it takes just write a record, but I want distribute on probably we don't connect at all like in the company within ourselves.

Like when you go and tell them I 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 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 working that lot of people ignore is designed

initially when we song, the companies are like around. 1020 people, we worked on projects. We used to produce really good code, but we were looking lot of times the founders of you smaller startups and Thing that we found was, people is very good engineering, but there are a lot of you, I was really bad. So the user behaviors were not very good. So then we bought in designers and that's when we found, we are producing very good engines, but not only just a sec.

The usability was very bad when designers came in and then we merge. The design is directly to the teams at a very, very low level. Then we start producing better cars. Are better bikes that I can say. It has better usability better things, but I can do the limitations of the budget of the customers and everything. So that's one thing that we all connected. We produce better software engineering quality with some of the core principles. So that's one thing. Thing. The second thing is

accountability. So we don't compromise on accountability. People have like a lot of freedom. It looks like a city, right? We thought of making it as a community. So from the beginning, even before covid, they're like, remote first, which means you can choose TV remote like any time but to be removed. 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 power back up.

No, you can't do that. So you mentioned for the first so good software, engineering practices first, especially within the remote setup. How do you ensure that such a good quality? Is a deer to by everyone in the company right in the team. Nothing is hiding itself. When you hire, you can't fire somebody who writes very, very bad code. Let us talk a little bit about hiring. So there are three dimension.

Hiring one is the skill set. 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 whole technical architecture, everything will be done by one person. And you are just allowed to only execute on the cards. You're not supposed to give your opinions or you're not supposed to learn bigger things. So you are seen at that level. How do you know they have? Like a lot of motivation. They always within that constraints. They write very beautiful gold. So they write unit tests properly. They follow develops as much as

possible when they do stuff. They automate things here. 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 do cries, obviously are making sure that whatever works in my machine works everywhere else, so 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 motive is a really high but their skill sets are limited by the existing company. So they're not able to learn or go beyond them. Then if you balance that you get a very good higher but you also get other kind of people. We are balanced on both motivation and their existing skills. It's as soon as you give them the coding Challenge on, try to see that code or give them a

system design. The really good then you are like, 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, non-voting, time you need to give balance for Some like some people have 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 element.

So, first thing, we started with hiring and making sure that is not compromised so much. And obviously when you do hire, you also make some mistakes. So there is a misfire. So then you try to course, correct. It keep tell them like clear. Goose. 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 will be mistake from our side like sometimes when I learned that, hey, Is a very simple thing I did 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 to have some personal, really some personal problem, and there is some

release. So they're trying to manage and relax struggling then that's where we tow spoke, right at the psychological when you are like well-connected and allow them like give them that space, there humans are not machines. Once you do them the feedback and try to understand what they are going through on and try to help them but even after doing that sometimes, it won't happen. Like they may be really good or exceptional Engineers, but the amount of gel with the team.

So they come in and The hard part where I say is that many companies was they're really smart and they pull through 80 percent of the load and just because of them the whole team is underperforming because they don't give up to other people. Now, at that point, you have to take a call that even if the city percent goes away. I have to give them feedback and make sure it is happening or just let them go. So it is firing, which is extremely hard to do.

If you are, not five much people, but first assume that it's your mistake, correct. It then understand what's problem from their side improved, give them time. But even after multiple times are not progressing, then the only thing that is of despairing, so, The way to help them after firing to find their jobs. Don't be too rude. So that's the second thing. Like again a said helping them is also a part of suffering, is what I feel. You're all humans soft.

Edging is not something really different from us. Now. The third thing is setting up the direction or like the problems different different people like different problem statements. So first thing is, how much Freedom can you do people to pick up their problem statements? If you hire somebody with particularly very good talent for something and they're like, very much motivated. They're 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 the third thing, like allowing 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 manager and also leader. So you have to put your manager hat and see what are the places I can improve things. A simple example is happens all

the time. You plan is print and in this print, 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 print that is much ignored we should be actually Spread all the cards that we most of the cars, not all the gods, all the cars that you would pick it up, can be tested only after one week or something, other than you are piling up the load.

And if the developer velocity is too high, then obviously, there's so much amount of vht driven because the district gets overloaded, they have to work on the weekends. And even if they work Monday or Tuesday, like the demo won't happen because the teaching of Snowden, if you allow developers to put code more than this, more risk getting produced. I think that's where you would put your manager hat. That's what bad things can happen to us in is opening.

So then you have to watch that. At behaviors and try to keep on fine-tuning. A lot of times quality is 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 it's not repeating. And again, if your pattern is repeating for a three or four times, then you're actually not

diagnosing the problem. But you are working at a surface low, you're just killing of the wounds, but you're not actually solving the problem. So you again Gaudi and try to eliminate the dust. If your just wiping every day and seeing dust coming in, there is some other source of the So you have to close the windows then obviously the stone come so you're always trying to diagnose and find the root cause not cure

symptoms. So Rhonda is 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 persists 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 three technical leadership wisdom that you would want to share with all of us the audience here.

Okay, that's quite interesting. So, I Try to tell a couple of them. The first thing is leadership is more about a verb rather than in known. 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. Then there is a problem. Everybody's looking at you. They are not looking around.

So then you are automatically leader. Then you do not have that noun, you're still at a verbal level. So that's very important. And interesting thing that I learned, the second thing is, it's completely okay to be wrong at leaders. So don't let the fear of experimentation. Like being wrong like 30. It's okay. To be wrong, just be bold, and then try to do things, and then expanding.

But make sure like, at least measure the blast radius before doing some experiments and put it in a safe place for all others because you are not alone. That's what's important. And don't think that I generally fell to us. It's okay to be rational 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 in

many times. Just before the demo, some people who commits and they're on the bill mostly, if you go and see in the end people, Who are like more experience? They'll never do that. They'll stop it. Just one day before, just for the demos. Even if it's a simple, internal demos will stop it. They'll not allow this thing to happen. It will say this is what we agree on. It's fine. There's overflow, we couldn't do

it, but we can't do this. But when you see, like mostly Jewish people, they come with that. Enthousiasm that, hey, I want to show more features in this demo and the push it till the last moment. And every time the demo phase, if anybody wants to give a rational argument that it's extremely hard. The same thing is estimations. There is this concept of dunning-kruger effect where people were like, let's experience. The think that there is

commission's are More, right. So these are all like rational, right? When I come and have this discussion with Engineers were like really smart. They'll say Hey try the previous Bill do that do this. But a lot of times they're like my new things that will fail. It's okay to be rational and then allow people to be relational sometimes but not for always say like you cannot say that. Alright additional code, that's not acceptable. So code is official to be

executed. So that's the third thing that I want to talk about. All right. So thanks again. Ranga for your sharing, the three, technical leadership wisdom. If people wants to connect with you online, where can they find you? Definitely clean. So I know that my name is really hard for not in India to pronounce search, but obviously, in the comments or somewhere you can search, my name is ranganathan Polish and mugam you can search or you can just search for Everest engineering,

which is easier. And my name pops up. Definitely good to connect and send a message on illegal in. And I'll be in touch. Yeah, I'll be surely. Putting that on the show notes. I mean, like, you're not alone. My surname was so kind of long and difficult to pronounce. So, thanks again for your time longer. It's good to chat with you and I wish you good luck with Everest engineering. And hopefully See you again in some other events. Thank you.

So much hundred was nice talking to you and I really appreciate the questions table. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really really helps me a lot in order to grow this podcast better.

You can also find the full show notes of this conversation on the episode page at technology. No, the death website. Adding the full transcript, interesting quotes, and links to the resources and mentions from the conversation. And lastly, make sure to subscribe to the shows mailing list on technology on of the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android