Amazon Leadership Principles博客文章 别人的笔记

Leadership principles 文章
https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d

Customer obsession 考虑客户需求/体验
We’ve regularly made decisions at Amazon which lowered profit/sales, because it was the right thing to do for customers. We all understand that the company performs better if our customers (and our employees) believe it’s acting in our best interest. We believe that’s the right thing to do, we make those decisions all the time, and we reward people for it.
you’ll know who your customer is, their needs, what they really want from you (outside of your specific tasks), and think about solving their needs, not just tasks.

Ownership 负责/帮别人忙
As an owner, that means that I am responsible when something goes wrong, responsible when decisions are made, and I act in all ways as an “owner” of the product.
And finally, if someone from AWS S3 comes to me and says they found a problem in my Android product, I’m going to be thrilled that they care enough. I’ll invite them to my office, see what they found, and discuss how we might fix it. Because we’re all owners and we all care, no one should ever say “That’s not my job”.
“I was their QA and they shouldn’t trust me too far with the code because I barely know what I’m doing laugh but when they had a few bad weeks and were getting behind on the bug queues, I felt I had to help. I started spending a few hours a day fixing bugs instead of testing. They were pretty simple bugs, but I felt it was a better use of my time, rather than finding bugs no one had time to fix. I just did my best to document things really carefully to make sure my help was a net benefit.”

Invent and simplify 创新
because there is always another solution. It’s just possible we’ll need to invent one.
we all firmly believe that the simplest solution is the one you can maintain, the one you can iterate on, the cheapest one to build, and so on. -> keep it stupid simple

When you realized the project review meeting wasn’t useful, how did you fix it?
“I canceled the whole thing. I realized the status we covered was already in our ticketing system, and I’d rather everyone spend that hour working. When in doubt, I always remove processes rather than fix them.”

Experienced software engineers know that the best engineers often remove code when solving problems rather than adding code. Removal is always a better option, when it comes to code, systems, and processes. Simplicity allows for faster and cheaper innovation, and that’s why they’re married together in this principle.

Are right, a lot
we need them to both have good judgment/instincts, as well as question their own decisions and be open to counter opinions.
We need our leaders to recognize that every perspective and opinion needs to be valued. And someone disagreeing with you is wonderful. It gives you a chance to reexamine your viewpoint.

Learn and be curious
What we do need is for you to be open and interested in learning new things.

Hire and develop the best
We believe that the top performers need our attention and guidance to ensure that they have the opportunity to provide their very best at Amazon. Spending time on our top performers is the best use of a leaders time.
Internal transferring at Amazon is an amazing and open process. We freely move around the company, and are able to self select our next job when we feel we need the growth.
Because doing things which challenge and scare you is the best way to learn.
We believe it’s the responsibility of every single person to help others grow.

Insist on the highest standards
If you’re an owner, would you be embarrassed or proud of the quality you’re delivering?
What it means is that we should never be satisfied with what we have.
We care that you are always thinking “I know we can do better than this”.

Think Big 想法要创新, 不切实际, 很大 (也许不可能实现)
If we are asking you in an interview for an idea, you can’t say the first small idea which pops in your head, and believe you’ve satisfied the requirement. When you’re asked for ideas, you should err on the side of being asked to stop. We’re always looking for bold vision (perhaps grounded in a small amount of reality), and need to know that our leaders are open to the idea of thinking bigger than the thing in front of their face.
When I’m interviewing someone, I prefer to think that someone’s idea is somewhat impossible, because explaining constraints to a co-worker is easier than explaining how to invent and think.

Bias for action 行动要快, 在做事情中学习,
We want those smart leaders to make quick decisions and move forward. You learn more from doing things and measuring rather than surveying or testing or projecting results.
We want leaders who take action, are bold, are willing to take risks, because they know it’s the right thing to do.
For software engineers, it’s a bit of a running joke about how many months it takes someone to completely break the service/system their team owns. Because it’s a part of being handed dangerous tools and responsibilities. For almost every major human-caused accident at Amazon, there’s a sheepish person who raises their hand and says “Yeah… that was me”. And they’re still here, because we value calculated risk taking.
We value this type of risk taking, because we need to move fast in areas where we can’t possibly know the right answer. Option A or Option B? Pick and move on.

Frugality 按重要的顺序做, 看之前的东西能不能继续用
This principle is all about ensuring that we can provide as much value for as little cost as possible.
We’re inventing to solve problems in a cheaper way. Which often is faster, easier to maintain, easier to extend, etc.
Then how did you fix the lead generation tool?
“Actually we really didn’t have the time to maintain it or rebuild it, but they really needed a tool to track their work. I realized that our bug tracking system had most of the features they needed. Certainly wasn’t perfect, but I explained how they could use it, and it worked out fine. One less system to maintain.”
When you’re interviewing, we’re looking for you to understand that having not enough time or resources is a fine and expected thing. Having too much to do, and too little time is perfectly ok. Not doing everything you want on a project is healthy, because doing everything you ever wanted to do is inefficient. The last thing on your stack rank will never be done, and we should all be happy with that.

Earn Trust
It’s very important for a leader to be able to recognize when they’ve made a mistake, so that they can correct it quickly.
When you’re explaining a mistake, first recognize your own, before explaining other misses.
It’s not about pointing blame, it’s about fixing processes.
We care about long term, not short. We care about fixing problems, not blaming. We care about honesty, not a story. We care about respecting those we work with, because we’re going to work together for a long time.

Dive deep
“Trust yet verify” is a favorite phrase at Amazon. We care deeply that leaders keep a careful eye on what they own, and know ways to audit their space.
We care that people know details, because it means they cared enough to question things. We need curious and skeptical leaders.

Have backbone; disagree and commit
We do things because it’s the decision we’ve made, and with the data we’ve gathered, we’ve committed to that plan. (不要说是老板说的)
Data based disagreements are great.
We believe that we’ll all succeed if we’re all on the same team. “I told you so” is never acceptable. We give data, make decisions, and live with the consequences as a team.
“I showed my boss the data, explained why option B was better, she pushed back, I suggested that we could try both options, she still disagreed, and asked us to move forward. I told my team we were building option A, and made sure to explain why it was the right choice. Because my team needs to know that we’re all on the same page.”
We need leaders who are able to recognize when disagreements are needed, and when they’re not. What’s worth arguing about, and what’s not. What’s worth escalating, and when it’s time to move on and start delivering. And we need to believe that you’re that type of person.

Deliver results
It is much harder (and much better) to focus on the business itself, rather than completing tasks.
What’d you do after you realized you couldn’t hit the date? (phone alerts -> email alerts)
“I looked at the features, and picked out a few I felt we could cut. The product manager agreed on a couple. Then, as bad as it sounds, I convinced QA to cut a week off the testing schedule. It was risky, but it was so important to hit the holidays. I figured we could test everything important, and it was the only way to get out in time.”
we’re all about delivering the right results.

Sure, let me tell you about the time I need to …. STAR – situation, task, action, result Situation: we are working on a project for a key client. 不要说太多没用的细节 Action: focus primarily on what you did, not what your team did. I did three things. First, I talked with… Second, I ….. Third, I …. We had two issues with this plan. Number one, we … and number two, we … Result: quantify your impact

故事1
Go through the workflow, think carefully before implement it, double check what would happen on each page, each button
UI/UX 加“save as previous” checkbox button, 加 “save this card’ checkbox button, 加 “confirmation ID” 在thank you page
Phone alert -> email alert ddl + we have email alert template and email alert API -> easier to implement before ddl

之前的错误/缺点
我以前有个xxx项目，太追求完美，导致错过了截止日期。我吸取了教训，有时候完成目标比追求完美更重要，在另外一个xxx项目中，我合理分配资源，即使有些东西没做到完美，但是在截止日前完成了任务，我向我的老板提了后续完善这个项目的方案，我的老板很满意

Due提前/好几个ddl
你是怎么管理你的时间的？比如日历上设置好项目，还有提醒；你会不会根据工作的优先级安排你的时间？你会不会为了项目组的整体利益考虑（best interest of my team），舍弃一些个人利益？比如为了毕设，自己的考试就不投入太多时间；会不会和别人沟通寻找解决方案？如果你是组长，你知道due提前了会不会采取措施？比如立刻开会，重新安排这个项目后面的任务和时间节点。-

队友/同事不同意你的观点咋办？
你有没有自己花一些时间做一个数字化（quantitative）的比较？有没有向队友/同事提交一个详细的报告或者比较（report/strong case）来说服ta？会不会有效的沟通？

队友/同事不干活/很难相处咋办？
你有没有经常和队友/同事主动沟通？你愿不愿意为了团队，帮队友/同事分担一些工作？能不能以非常职业的方式解决这个问题？

为什么你是xx专业，却想做sde/ds/mle？
你之前哪段项目/实习经历做了有关sde/ds/mle的啥？你产生了啥影响，取得了啥结果？你是不是很享受你的产出？（是，所以我想转）

Link