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.