更2019/07/18,因在亚马逊这么久,级别也跨越了这么些,就来说说关于在亚马逊的技术类人员的个人发展和升职吧,我想大家还是比较关心的,希望有所帮助,欢迎讨论。前一阵回国度假,所以有点时间了。想到哪就写到哪吧。
关于为什么升职,应不应该升职
这两个问题个人感觉挺重要的。我想升职为的是:更广的技术视野(为以后那么微小的创业可能性打些基础),更多的决定权和更多钱。
其中,更广的技术视野是我一直最想追求的。事实证明,到了Principal级别后的确视野会非常广阔,会比SDE 3时广阔几倍。首先,因Principal人数有限,所以直接来找你来讨论项目和拍板的人会成堆,你接触到的不同项目也就会非常多。其次,升到Principal之后会被拉入专属的邮件列表,每天有这天南地北的讨论。然后还有公司各个部门提交的Principal咨询,找相关Principal来咨询项目的技术方向。最后,你的话语权会变得很重,所以你老板或者你老板的老板或者你老板的老板的老板会带着你去各种项目讨论会里讨(si)论(bi)。
你如果暂时不清楚你是否想升职,或者不知道为什么升职,没关系,也可以一步一步来,有的时候在过程中会慢慢知道的,但尽早知道,不然会变得迷茫,比如“我应该继续技术路线呢,还是走管理,还是产品?”
当你升到SDE 2时,你就会有机会选择不同的方向。在这时,通过和老板沟通并且问自己几个问题来判断是否要继续走技术的路线:1. 我对技术感兴趣吗 — 平时闲暇时间会不会自己写些代码,会不会买技术的书来充实自己,会不会对最新的编程语言,操作系统,框架,算法感兴趣?2. 我有没有找到我技术方面的专长?3. 我是更喜欢自己设计系统写代码做出项目呢还是领导其他人 (Engineer vs Manager)?4. 我是更喜欢设计系统写代码呢还是想出更好的产品?(Engineer vs PM) 5. 我是更喜欢设计系统写代码还是计划和执行项目?(Engineer vs TPM)
关于领导力原则(Leadership Principles, LP)
在亚马逊,这可能是最重要但同时很难理解体会的东西了。亚马逊的理念是他招的和培养的是领导者。作为一个领导者,你需要具备一定的素质,这些素质是通过14条领导力原则所体现出来的。这14条在网上能搜出来,就不一一说了。
理解和体会到所有的原则需要时间和经验的积累。其中有一条稍微难理解一点:Bias for Action。其实这一条你做起来比理解起来还容易点,因为在你还是SDE 1/2的时候,做的应该还是挺多的。但随着升职,当你所需要做的决定越多和其影响力越大,你做决定时所需要的数据就越大,压力越大,判断力要求越高,做到这一点就越难了。亚马逊是很讲求数据来驱动决定的,但当你无法获取足够的数据来支持你的决定时,你能否果断的但又同时高质量的去给出一个解决方案,能否有足够的责任感去承担风险,能否快速的让客户得到回报,这就是Bias for Action所考察的东西。Facebook当年的格言就是Bias for Action的初级表现,但当公司变大,客户变多,影响变大后,是否还能够做到这一点就很考验了。
关于升职的几大要素
技术人员的升职其实主要就是看以下几点要素:
1. 项目复杂度(相关的LP: Dealing with Ambiguity, Invent and Simplify):分为问题复杂度和技术复杂度。问题复杂度主要说的是你需要解决的问题是否直观还是存在许多的不确定性,是否已经完整的呈现给了你还是由你自己分析出来的等等。技术复杂度比较好理解一点,比如需要handle多少TPS,latency需要多少,处理大的数据量,精确度和召回率分别为多少,对其他项目的依赖有多少等等
2. 项目完成度(相关的LP: Deliver Results, Insist on Highest Standards):很好理解,你所立的项目有没有很好的按时并且高质量的完成。
3. 项目影响力(相关的LP: Customer Obsession):任何做的项目都会有一定的影响力。一般来说都是对客户的影响。比如通过A/B测试,你的项目提高了10%的活动用户或者产品销量,那就是挺大的影响力了。
4. 个人影响力:这个指的是你在项目以外有没有对部门甚至公司产生什么影响?比如你开发了什么通用的框架或系统(Invent and Simplify),有没有积极的参与了design review (Insist on highest Standards),有没有帮公司招到人,有没有的去带身边的同事升职(Hire and develop the best)
5. 个人能力:这个主要看的是想法(Think Big),技术,沟通,计划,执行和评论这几个方面。技术不用说,很好理解也很容易体现。想法主要讲的是创新,分析的能力,比如是否主动的去思考过新的有意思的项目,是否主动的去分析过已有系统的优缺点并提出建议。想法有了,就需要沟通。一般来说,沟通是通过文档的方式,PRFAQ,design doc甚至简单的邮件都是沟通的方式。沟通得当的话就能够说服老板或者产品经理去立项,然后开始考察你的计划和执行能力。亚马逊之所以有Leadership Principles,是因为他培养的是领导者,作为一个领导者,你就不光需要技术这么简单了。
一般来说,升职需要通过3个左右的项目来体现你的成熟度。亚马逊需要你证明在过去的一年内有稳定的体现出下一级的成熟度,也就是说升职代表你已经到达了下一级,而不是在升职后你能够到达。帮助我升到Principal的项目有好几个,有技术复杂的,有完全是靠我自己从一个抽象的想法做到最终产品的。我认为最重要的还是主动吧。主动的思考,主动的写原型,主动的写文档,主动的沟通想法。这一点上来说老印们会强一些。
<hr/>从11年入职到现在,在亚马逊一呆就是七年半,转过三个组,从SDE1一直做到Principal(4月升职 :D )。对亚马逊的印象还是非常好的,有过很多良师益友,能够学到的东西非常多,不论是技术,商业还是管理。当然,这也仅代表个人看法和经历。
首先,在亚马逊你会遇到各种各样厉害的人。其次,亚马逊(也包括其他大公司)的公司文化对人的影响是很大的,一旦你适应了,你会不自觉的去用来评判人和事,很有效率。
从刚入职到现在,我所合作过的很多人(SDE, SDM, PM, TPM)都各有各的厉害之处。比如我现在的Manager,想法巨多,也很长远,但也很实际,当年一个人做出了某个功能的原型,然后成为某个产品的顶梁柱之一,不得不佩服。当然,我也见过不那么厉害的,但大多时候是无法适应,而非个人能力。
刚入职的时候不太懂leadership principle是啥,只知道写总评的时候要用到。随着经验的积累和级别变高,会发现这些原则是着实有效的,不论是对人还是对项目。比如某个项目无法获取所需的所有数据来作出决定时,你是会选择继续Dive deep还是Bias for action?在评判某个人时,他/她是否能够独立的做到deal with ambiguity?这些都是一个大公司长期积累而来的精髓。如果某一天我要自己创业了,这些原则也是我能够带到我的公司的实际内容。
我是一个看重产品和项目的人,喜欢自己没事做一些产品原型。这一点我所在过的团队都很欣赏和鼓励。亚马逊的文化是work hard, have fun, make history。他注重努力工作,注重客户至上,注重用简洁的方法来解决复杂的问题。很多时候这些就代表了operational load很重,oncall会多,但同时也给了我很多学习的机会,比如如何架构出能够处理亚马逊数量级的服务来,如何才能减少operational load,如何自动化。想在亚马逊适应,存活,就需要时刻的思考着,不是解决了一个问题就停滞,而是不断的去寻求改进,不断的去反思过去。亚马逊的各种机制也是为此设立的,比如出名的COE。这也是让我喜欢的地方。 |