Hey, guys thanks a lot for clicking on this video.To get into Amazon, it's not just about coding, but it's also about 14 leadership principle
that they ask vigorously in each and every round of their interview.It can be the deciding factor, whether you are getting the
job or you are rejected. So,you have to understand each and every principle in detail along with the example that you
may need to demonstrate in your interviews.so,please go through the video completely, and find out how you can apply
these leadership principles in your professional life.We have invited Kumar Vimal from Texas,U.S. who has been in Amazon
for 5 years, and is well versed with each and every principles. So, let's welcome him.
AMIT:Hey,KV.Thanks a lot for joining for the call.
K.V.:Thanks Amit for having me here.I'm really excited to be a part of this.
Today, we gonna discuss about the 14 leadership principles of Amazon. So, people say that these principles are not
applicable in professional life. So, as you have been in Amazon for 5 years,I thought of inviting you for this and discussing with
you, how can somebody actually apply these leadership principles.
Oh, this is a great topic to discuss.I'm sure that I can share a lot of experiences on this, as we go through the individual principles.
Okay KV, let see about the 1st principle. Customer Obsession.This is really a dicey topic, people easily don't understand it.
We are developers, how can we think about the customers directly! So, can you just give some scenario where a guy
can show customer obsession being a developer.
Amit, according to me this customer obsession term is really overrated term.This principle is pretty simple, you just need to
think about the whole problem by putting yourself in the customer issues rather than getting fancy about your solutions or start making
complex solutions or focusing on such other things, which is not really important in the first go for the customers.
I have a good example, when I was working on maps, my team was making a important page, where we have to show pins for all
the service providers.In that thing, being a regular developer, you would be feeling like,I will make it feature rich and will add zooming,
panning and all that gestures that we learn on our JS layer.I will use really cool gestures to deliver this thing.
But, if you look it from customer perspective, that is not what will draw your first customer, right! When you are launching this product,
when you will be in the private beta and launching it for the few customers, they like if the UI is kind of responsive.
So, we should focus on the latency aspect, more than getting along with the thousand of features.Just pin down to having a basic UI,
with the basic functions, where the latency is always in check.You are not having more than 50 milliseconds.
I'm just putting a number, this reads called up UI, where you can have not more than 250 milliseconds.But I am saying,
more responsive the UI is, more will be the adoptability, and you can add on more features as it goes on in the project.
So,KV that was a great explanation.Coming to the next principle.The next principle is ownership. So, say something about it.
I think before I go on describing the scenario, what do you feel about this principle,Amit.
Okay, so I was just waiting for this. So, ownership, what I understand is this, as it is written also that you don't only act
for your team, you also act for the entire company.That means, if something is blocking you, you take the responsibility
of fixing it.Even though that code doesn't belongs to your code base.For example, if you are building some feature and
your dependency is on another team and to unblock you feature, you have to scan through their code base, understand the problem.
If you need to fix the problem, then fix it.Show the ownership for your feature and also unblock other teams. So, am I correct!
Yeah,I think that's a very well described scenario to demonstrate ownership.You should never think, others team code bases
is not your own and this is not my job.I should go ahead and do this. But, everything is all tied up.They are your dependencies.
You should go ahead and look at, how we resolve those.And get going with our own project, post having that work done in the
waiting moments. That`s a very well described scenario Amit.
Let's move to the next principle, invent and simplify. So, what I understand from invent and simplify is, keep it simple.
If the problem is complex, it doesn't mean that your solution also has to be complex.If the complex problem arises, in the
beginning, complex middleware, complex algorithm should not be applied.We should always think, how we can simply solve
this problem.And I think this will save company's time and will also boost your productivity.
I think that is pretty much there Amit. Means, when the problem comes, we being developers try to apply all the fancy knowledge
that we have till now. Like, let just apply all the technologies, in this project, that we have learn so far and have to show,
what these technology can do. So, a very important understanding being a developer is that, you start simple and that what leadership
principle advocates.The problem space might be complex, but you start looking at the solution from a very simple point of view and
develop which is simple.This thing has so much of pros. Today, technology is emerging every time, even if you come up with
complex solution, its not guaranteed that it would stay for a very long period of time.Its also increases our operations.
If you have complex solutions, you also need to have all the matrix around, every code of the complex solution.
It also impact the operations.According to me, starting from a simple solution which caters all customer needs is more important,
and is a big time, when, for not just the customer but also for the team in managing the product.
I think that's a great, great explanation.Let's move to the next principle. Are right, a lot.
None of the principles is simpler than this.I think it means that leaders are always right and should always be followed.
I think you guys follow this only.Right! That leaders are right.
I think this is a very wrongly interpreted principle. I know why it is because it says, are right a lot.
But, if you go down understanding this principle, it's all about data driven decisions, having to make decisions at every level.
It doesn't mean that,I am the new hire for the company,I cannot take decisions, let me describe it with a small example.
There was a very mature product, that we had in our team.That product was running in production for about 3 years.
The leaders believe that we are good with just having this product in the keeps the light on mode, since it was very mature product.
But, the low level understanding on operation does come when the developers have their own calls.You kind of understand
there are a lot of optimization that you could do.And these are never prioritise because, you know, from end user perspective
our customer perspective, you don't really get any benefit from picking up those tasks and sprint.
If you apply this principle, you should always look at the matrix, look at all the data that you have and go talk to your leaders,
that this is something we believe is taking a lot of time operationally, we should have this in our sprint and prioritise this feature,
so that its a win-win for every one, for the team and for the company.
Oh my god! I didn't know that it has so much of background.I thought this principle was simplest.But,I think this is the most complex.
Moving on to the next principle.The next principle is learn and be curious.I think I will get this one right. So, learn and be curious
is I think pretty simple, just learn and be a curious man! Like keep on learning at every level, even if you have become a principle
engineer or some very big guy.Even big CEOs, they never stops learning,I think that is the mark of the leader that they keep on
learning and their curiosity is always high. So, it's pretty simple.
Well, yeah in that sense, yes. But, there are nuances and I think let me describe a small scenario to describe how this principle comes into play.
Our team was working on a work-flow engine and developing business needs on that same work-flow engine for years.
And what happens, when you work with a particular or platform, you pretty much resist changing that because every developer
becomes cozy and comfortable with that technology and coding on it. But, with every task that you do and at least for the tasks where
its gonna have a long-term impact on being used in the team, you should definitely think about, what is the latest of the greatest in the
market.Am I having other solutions, that can make this development process simple.I can bet you, you will not be able to do this, if you have
not accounted for the time when you were doing sprint planning. So, a very important things to keep in mind, you bake in some of these
development times, right at the time of planning your stories.
Okay,I think this sprint planning tip is very useful for many people.Even,I don't get a lot of time for learning, to be very honest.
Let's move to the next principle.Hire and develop the best. I think this is also so simple! Just hire the best candidates, right!
Hire good people, that knows to code and help them to develop.They know coding and now, here they will do development.
Okay,I am just joking. So, what I feels is, you hire the good candidates nad you develop them, nurture them.You try to find their key strength
and weaknesses and give them opportunity to grows as leaders.So,I think its jest is that the overall development of the individual
should be taken care of.
That's true.For understanding this principle, let me give a small scenario which happened in my team.
I have one good friend in my current team.We were working in the same office for around 3 years. So, for having to work for such a long time,
you get to know a lot of domain knowledge.And this friend of mine, he was always curious, questions, why are we performing these tasks,
why are we not picking something else which gonna bring more returns to our end users.There is always a thin line between balancing what the *
vision of the team is and what the customers demand are, what immediately you should solve for. So, he always want to explore that
kind of work stream, so, our leadership did acknowledge this fact that hey man, you understand this phase really well.
So, they did give him opportunities where he could help the leadership with setting up the right priorities and aligning with
long term chart up for the team. He did also shadow other technical program managers, that whats role fits him well. And he actually has
finally move to, currently being a technical program manager in the same team. So, that the example of, how the leadership principle is
demonstrated
I think, indeed, this is a really good example. So, lets move to the next principle, leaders insist on highest standards.I think, this is also not
very tough. So, what I think is leader will not compromise with anything sub-standards, they will always go for the perfection and they will have a
really high standards and their subordinates too, may find it unreasonable at times, as here is written.So,I think this principle is not
that tough but it can be tough on the employees at sometimes.
Yeah,I think, leader should always have this notion where they are bringing this positive change and raising the bar on the entire code
quality.And,I can remember of one small scenario, where this principle can be seen in action. So, we were developing on a product,
where we write unit test code and functional test were never really prioritize. Again, same reasons, end users don't get to have any
benefits from these tests, but if you look at code quality and catching edge cases, catching bugs in your pipeline, its very tough to not have
automated test and believe, everything will go fine in production. So, this is one example where I feel, we should always insist on the highest
standards and raising the bar of code quality in every project.
So,I think that's another good example. So, let's move to the next principle.Leaders think big.Okay, I think I completely get this one.
Because you don't built system for today.At present, your system might be small, but it should be extensible for tomorrow.If you are working in
startup, but, if at present that startup has 10 thousand customers, but tomorrow, it may have 10 million customers.So, the system should me made
such, that its extensible to cater the need of high volume also. So, is it correct!
Yes.I think.The scenario that just talked about was already very good example of this principle.I remember, we were working on one of the
project, where we gonna launch project in private beta and when we were designing, everybody was thinking, there will be only 10k customer
and whatnot! But, it's always important to understand the scale is always growing as you move on with may be the public availability of
API or whatever it is. So, we should always keep in mind that system that we have, designed for right now should be able to manage scale at
large and be just extensible enough to more diverse business use cases.And you don't like take very short -term decision on your current
approach.
Okay,I got this one. I think I was pretty correct.Let's move to the next one.Leaders have a bias for action.I think it can be easily
misunderstood, because it look like leaders will take rash decision without thinking too much, they will directly act. But, what I believe here,
as we can also read that the decision that may not impact customer directly or that can be changed or that can easily changed later on,
those action should be taken without too much deliberation, they should be taken quickly and I think this will increase the overall turnaround
time.
Yeah, I think, as I say,I have a good example of, where you can see this principle in action. Suppose, you are working on APIs and you wanna
expose these APIs to the end users, for setting up the contract of the APIs since they are gonna be vended out, you should definitely take a
lot of time and patience in designing the contracts. But, if you look at the other aspects, the internal aspects, where you are using some
technology for perhaps queueing or take the example of cashing. So, cashing strategy do change over time, and you might wanna
learn from the initial launch and go ahead and revise it.You don't necessarily have to spend a lot of time, that I will get the best one in the
first shot!
I think cashing was the really good example. So, let's move to the next principle.The next principle is frugality.So,Amazon is famous for this
principle, to be honest. So, what I understand from this principle is,cut down your budget,
K.V. : I am pretty sure, its always gonna be! People don't understand it, right. But, I would like to hear from you, what you feel about this one,
what you understand?
I think, frugality is a very Indian thing.Coming from a middle class family,I think my dad was also very frugal. So, he is still a very frugal person.
So, main thing is, you don't do the things that are not needed.You only do the things, you only allocate the resources that are needed, just
enough, nothing more nothing less. So, you don't do unnecessary things and I think that is frugality.
Yeah, i think,I have a good example from what I understand, when my team was working on the projects, where we had to send the email
notifications. So, you don't necessarily invest in queues, where you have to pay for the strict ordering as well.You kind of get a very basic
implementation done because you don't really care about that aspect and you start small, you start with a queue, where you don't have to pay
that extra strict ordering feature because we don't need it as if now and don't envision to see that in anytime soon. So, that's what this principle
says.Spend money only on products, which is really gonna bring benefit and not overspend.
Okay,I think our understanding coincides quite a lot for this one.Let's move to the next principle.The next principle is to earn trust.
So, what I understand.Let's leave the text and tell you my understanding.It may be very incorrect also. But, what I think is,
you earn trust by showing your true nature, you earn trust by becoming a good listener, you earn trust when people believe that you are a good
contributor to the team, that you value the other person's opinion. Only then you will be a trustable employee or a trustable colleague.
So,I think earning trust is the more emotional side of the thing that keeps the team together. So, yeah, thats my understanding,
what do you say about it?
Yeah,I think, you are pretty much right Amit.This kind of leadership principle, which is to do with, how you interact with others, how you
win over the trust of others.So,I remember a scenario here, when I was present in a design,I had all the data points of, why my solution
is the best solution ever. But, when you are bringing your design in the forum, everybody will have the their own set of points and reasons to
prefer one solution versus the other. So, you should be very patient with hearing out with every data points, all the data points from all the
different members in the forum and not kind of shadow them out. Because, everybody loves to have their voice being put out their,
you don't necessarily need to take decision then and there itself.You can just say, hey, let's all decouple the process of decision making
from the process of presenting the data points and that is something, a leader would always do. Hear out all the data points, from every member
in the forum, so that everyone feels significant.Respect their voice and at the end you can summarize all the data points and take the right
decision on everyone, after hearing from everyone `s data points.
Okay,I think I totally understand it now. So, moving to the next one.The next principle is dive deep.So,I think this contradict with initial principle
of bias for action.I don't understand, how can we have bias for action and also dive deep. But, let me tell you my understanding.
So, dive deep is time to investigate problem to its core, and trying to find the real the reason of everything and leaving no stone unturned.So, if
you have a problem, dive deep on it.So, this is my understanding.
Yeah, so this principle is effectively is to do with, going down more layers and understanding what real root cause of customer behaviour
or change in system behaviour is.I can have a small example here, whenever you get a high severity ticket or you have some issue
going on in production, first thing that you definitely need to do is, understand how you mitigate that. And, you should definitely do all
that comes in your way to stop the bleeding as soon as possible.Show your back as per action in actually mitigating the high severity ticket.
But, in other side, after the mitigation is done, what you should always do is, go to dive into the different aspects of what really was wrong,
where we were not having functionality test, that could test that scenario or is that scenario very difficult to test in the first place, are we using the
wrong set of technology, can we right something which is simple enough.You should kind of ponder and think about all the different
vertical of the problems, after the mitigation step is done, so that you fixed this problem, not just for the high severity ticket that you just
received, you fixed it for a quite good amount of time, so that you don't have this problem coming up again.
Okay,I think, now understand this principle quite better. Let's move to the next principal.Leaders have backbone, they disagree and commit.
Again,I feel a bit in contradiction with the earn trust. So, the earn trust leader:Okay,I want to listen to you, please tell me what you want to say.
And here, the leader have a lot of backbone, they are like disagreeing, voicing their opinion, being challenging others. So, its quite different
from earning trust, but what my understanding is, of course, if you have an opinion, have reasoning for it, have backbone, but if you are convinced
with the other person, then just commit to it.That's my understanding.
Yeah,I think, you are pretty right.This principle says that, quite a bit of time you land up in situation where the forum is with a particular notion,
they all support a particular decision or a particular approach. But,you inherently have a different set of data point to support a different
approach all together.You should not shy away to present that in the forum.You should give all your data point that you feel is applicable to
support your approach or your solution that you have in mind and then if the forum decides to go the other way around and if there is good
enough data points to support the final decision, you should be also commit wholly to the final decision and not go two ways on it.
So, there should be just one decision at the end and then you should be definitely satisfied with the data points that were presented. And, if
not good then question them. But, at the end, you should always be satisfied and come out, after the meeting with just one decision
with every one agrees on.
So, finally let's move to the last principle, deliver results. So, what I understand is, if you are a leader, if you are not a leader, if you are
anybody, if your employer is paying you, you should be delivering results,I think on time. So, that means your deliverable should be on time
I think you should have strategy to plan your deliverables, how will you breakdown the task and make things possible and I think this is a
very important principle for anybody.
Yeah,I think deliver result is something that you always practice on the day to day basis, when you are working on projects, you don't really
want to miss deadline. But, if you think of deadlines which comes with a lot of customers impact. For example, the Diwali sale in India,
you definitely would like to reach a couple priority if there a lot of items in your backlog and pickup the right items in your scrums, so that you
don't miss upon such big event because these come like just once a year sometimes. And, groom your backlog in such a way that you
complete all the tasks on time and go ahead and release the product on time.
Okay,I think the main thing is on time delivery. So, thanks a lot K.V. for explaining all the 14 principles.I think its the delight for our viewers to
get to know all the 14 leadership principles from a guy, who has been in Amazon for 5 years.
Hey, it was pleasure doing this with you,Amit.I am sure people will find this insight-full enough, at least on some of the practical example and
scenarios, we did talk about.I am pleased to be on your channel today.Thanks.
I just wanted to says, it's not my channel, it's ours channel. So, hey guys, if you like more such videos, please press the bell icon and like this video,
share with friends and prepare for the FAANG interviews.
Hey guys, don' t get obsessed with FAANG.Find the job, find the role that works for you.
Peace! Peace!
