Review week1: Amazon 的领导力法则

用户头像
猫吃小怪兽
关注
发布于: 2020 年 05 月 21 日
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.



发布于: 2020 年 05 月 21 日 阅读数: 36
用户头像

猫吃小怪兽

关注

还未添加个人签名 2019.12.17 加入

还未添加个人简介

评论

发布
暂无评论
Review week1: Amazon的领导力法则