Review week1: Amazon 的领导力法则

看眼缘选了一篇文章：3 Learnings From a Software Engineer at Amazon



这篇文章开头讲自己已经在Amazon工作四年，在同事们的熏陶之下，慢慢对领导力法则有了一些感悟。中间分段落列了三大感悟，分享完结表示他仅代表个人不代表公司：）求生欲也是非常强烈。我们一起来看下这三点究竟是什么。



1. 用户至上。

无论在哪个项目阶段，都应该从用户的角度思考。产品设计之前也应该先收集用户反馈。

但对于技术人员来说，我们不仅要为客户构建产品，还必须构建可维护的产品。毕竟没几个人能给垃圾代码接好盘，这样后期必然会影响产品功能进而影响用户体验。所以考虑解决方案的时候最好综合考虑问题：

a. 正常人能用明白吗？

b. 什么时候会故障？该怎么预防或减轻它的影响？

c. （需求、规模）扩展性怎么样？能满足5-10年后的需求吗？

d. 有更好的解决方案吗？

e. 用户和企业可以做到双赢吗？

f. 整套流程可以很好地自动化吗（部署、测试、回滚、异常处理等）？

讨论出好的实现方案，需求写完了就完了吗？不。了解客户喜好后，你还可以主动开发新功能来取悦金主爸爸。



1. 建立共识。

亚马逊的工程师文化要求他们坚持最高标准并拥有反骨，这有助于写出卓越的代码，但是也有助于引发工程师吵架。吵架的原因有很多，比如

a. 选择自己的解决方案可以获得个人利益

b. 缺乏处理不一致意见的流程

c. 对问题的研究不足

那和别人出现分歧的时候该怎么解决呢？作者也提出了一套流程：

a. 保证对方数据驱动的论点，这是battle的前提。提出问题可以使对方知道你正在考虑他们的想法，而且会使他们对自己提出的解决方案更严格的思考，如果存在漏洞，分歧可以解决。

b. 收集其他人对解决方案的反馈，列出利弊。可以在原型设计和测试之后，让其他人选择最佳方案。这样做可以借助他人的专业知识扩展自己的视野，可能使一个想法最终变得比另一个更好。

c. 如果其他所有方法都失败了，让负责人拍板。



1. 扩大影响力。

扩大影响力的成功程度可以归结为是否赢得了同行的信任，以便你的想法得到考虑？

a. 在自己的团队中拥有成功交付的可靠且一致的往绩记录。

b. 与其他团队进行跨职能合作的项目中，在了解该团队的服务及其流程之后，可以提出以前从未考虑过的改进和做事方式的建议，这使你有机会影响该团队的技术方向。

c. 积极参加跨团队会议。亚马逊每周举行一次会议，主管下的所有团队将聚在一起讨论该周的运营问题——这又是一个识别其他团队的潜在问题，并为其提供解决方案，帮助减轻运营负担的机会；每季度举行一次会议，讨论我们的发展方向——这些会议提供了提问的机会，如果觉得某些事情没有被考虑或可以做得更好，可以再次提出建议。

d. （个人认为不适合国情）如果没有与间接上级进行过一对一的会议，可以约一次，讨论自己认为有效的问题，存在的问题，提供解决方案，并根据一系列解决方案提出建议。稳妥起见，请始终保持自我批评的态度，重新分析问题的解决方案，向他人介绍您的想法并加以完善，然后再向管理层提出。



-----------------------------------------------------------------------------------------------------------



“求其上者得其中；求其中者得其下；求其下者无所得。”leadership是每个员工都应该锻炼的能力，不管做技术还是做管理，都需要技术影响力。只有提早做好准备，才不会错过机会窗口。

不过我这等初级程序员还是先去学基础知识了（



一些有意思的表达

drinking from the firehose: to be overwhelmed (with information, work, etc.); to do something intensely; to be inundated



one side of the aisle: used for referring to one or both major political parties in the U.S.