亚马逊那种直接鼓励竞争性的角斗士文化本身就有非常大的争议，其本身确实不是以优先考虑员工感受为出发点，但作为亲历者也确实能够感受到在压力下不断创新和超越自我所获得的满足感
宇宙对我们说不，但我们以血肉之躯来回应，大声说‘是的！’”——RayBradbury
我自2009年加入亚马逊至2014年底离开，期间接触了多个团队的技术研发和研发管理的工作。在离开亚马逊加入创业公司后，研发团队遇到的一些问题常常将我带回对往事的思考中：“是什么让亚马逊的研发如此不同？”，“如何学习亚马逊的经验来打造高效的研发团队？”……。
本文正是我近几年对亚马逊研发和管理的一些思考，并结合了具体实施的一些经验。由于整个亚马逊的研发和管理体系的复杂性，加之多数结论也是基于实践的一些揣测，其中不乏不妥和错误之处，望阅读的过程中加以斧正。
最后，亚马逊那种直接鼓励竞争性的角斗士文化本身就有非常大的争议，其本身确实不是以优先考虑员工感受为出发点，但作为亲历者也确实能够感受到在压力下不断创新和超越自我所获得的满足感，因此，有关文化的讨论并不是是非对错的探讨，读者还需要自行判断和采用。
成为全球最以客户为中心的公司，在这里，人们可以找到和发现他们想从网上购买的一切。
——亚马逊网站使命宣言
Bezos通过一张图（如图1）诠释了亚马逊的运营逻辑，这逐步演化为整个亚马逊电商的运营核心——飞轮（Flywheel）。这个飞轮简单解释如下：
亚马逊提供丰富的选品和购物便利，而丰富的选品和购物便利带来了更好的用户体验，用户体验的提升引发更多的消费者来到网站，流量的提升将吸引更多的供应商加入，结果进一步丰富了选品，而这又使得亚马逊可以通过供应商竞争以及在更宽泛的基础上分摊成本来进一步降低价格，价格的降低又使消费者的满意度进一步提升，这个良性循环持续发生，推动这亚马逊整个平台越来越好。
在亚马逊的研发体系中，类似飞轮这样的良性循环机制发挥着广泛而巨大的影响，大到人员招聘和培养体系，小到事后分析机制的设计，甚至亚马逊平台化的思路中也多有类似的飞轮思想。【注4】另外，之后将要介绍的领导力准则，其各个部分往往也会相互影响，形成类似飞轮的机制，正如JohnRossman在《TheAmazonWay》中所说，“一旦你在组织中建立起责任感（Ownership），它就会像飞轮一样驱动着创新与简化（InventandSimplify）”。
“Itwouldcertainlybemucheasierandsociallycohesivetojustcompromiseandnotdebate,butthatmayleadtothewrongdecision.”
TonyGalbato,Amazonvicepresidentforhumanresources
HaveBackbone;DisagreeandCommit.Leadersareobligatedtorespectfullychallengedecisionswhentheydisagree,evenwhendoingsoisuncomfortableorexhausting.Leadershaveconvictionandaretenacious.Theydonotcompromiseforthesakeofsocialcohesion.Onceadecisionisdetermined,theycommitwholly.Theyarewillingtochampionanunpopularordifficultmessage.
首先，《一键下单》用这个故事表现Bezos缺乏同情心：
贝佐斯天生就没有同情心。他10岁时，在和祖父母的一次旅行中，他试图让他的外祖母戒烟。对于一个让人难堪的话题，他靠的更多的是他的书呆子办法而不是善解人意。他算出她所吸入的尼古丁含量会减少她9年寿命。外祖母哭了。外祖父不得不教导他应该有更多的同情心。“我外祖父注视着我，沉默片刻，然后平静地轻轻说道，‘杰夫，有一天你会理解，做到善良比聪明更难。’”贝佐斯说。
JeffBezosturnedtodata-drivenmanagementveryearly.
Hewantedhisgrandmothertostopsmoking,herecalledina2010graduationspeechatPrinceton.Hedidn’tbegorappealtosentiment.Hejustdidthemath,calculatingthateverypuffcostherafewminutes.“You’vetakennineyearsoffyourlife!”hetoldher.Sheburstintotears.
最后，Bezos自己在普灵斯顿的毕业演讲中[9]，用这个例子来说明选择比天赋更重要【注8】：
……Mygrandfatherlookedatme,andafterabitofsilence,hegentlyandcalmlysaid,“Jeff,onedayyou’llunderstandthatit’shardertobekindthanclever.”
WhatIwanttotalktoyouabouttodayisthedifferencebetweengiftsandchoices.Clevernessisagift,kindnessisachoice.Giftsareeasy--they’regivenafterall.Choicescanbehard.Youcanseduceyourselfwithyourgiftsifyou’renotcareful,andifyoudo,it’llprobablybetothedetrimentofyourchoices.
有别于其他企业夸夸其谈、含糊不清的的价值观，亚马逊的领导力准则从来不是埋藏在员工手册中的漂亮文字。这些信条在整个公司范围内——从上到下——被用来指导日常工作、绩效评估、人员招聘，甚至被用来解决会议中的争论、跨团队的协作（如图3）等等问题。亚马逊领导力准则就像亚马逊这头巨兽的血液，它在思想层面统一了亚马逊人对做事方式和做事标准的认知，并提供了一套高效沟通的标准语言。【注10】
图3在日常邮件中使用领导力准则进行沟通，反馈问题，给出解决的建议。
此外，通过领导力准则在人员招聘和绩效评估上的使用，亚马逊将这些能力固化为亚马逊人所应具备的标准竞争力（Competence）。比如，亚马逊的绩效评估使用OLR（OrganizationandLeadshipReview）的机制，其中L就代表了领导力准则（LeadershipPrinciple）。评估分成3个部分：员工自评，经理评价和360度互评。这些评价都需要落脚到具体的领导力准则上，并且要给出具体的改进建议。
为了使这些准则明确和更具操作性，亚马逊还为每位员工刊印了指导手册，里面具体解释了使用方式以及使用过度和运用不足的情况（如图4）。而且，作为指导亚马逊日常工作中决策的依据，其与公司战略和人员情况始终保持着紧密的互动，也就是说，这些领导力准则会被定期评审以判断是否适用，例如，最近自我批评（VocallySelfCritical）就被好奇求知（LearnandBeCurious）取代。
那么，我们要如何学习亚马逊的领导力准则呢？
Bezos期望通过领导力准则让每一个亚马逊人成为企业的领导者（leader）或者主人（owner），他想让你就像对待自己的事业一样来推动亚马逊的业务，而不只是来上班和社交。这也正是许多企业主和管理者的所面对的问题，在这方面亚马逊确实做得不错，但是这样的角斗士文化并不适合每一个人。对于企业而言，我们能够借鉴亚马逊建立更为适度的竞争环境？而对于求职者来说，你是期望一个不断将你踢出舒适区并不断促使你成长的环境，还是一个舒适的工作，这取决与你的选择。
实现跨越的公司的领导人不会追求这样一个领导模式：“先普遍撒网，后重点培养”。而是走这样一条路线：“我们会事先花上大力气进行严格的人员挑选。一旦找对了人，就会想方设法把他们留在自己身边。如果不合适了，我们也会诚实地去面对，这样我们可以继续我们的工作，他们也可以继续他们的生活。”——《从优秀到卓越》
文化的受众、组成与影响的都离不开人，可以说，文化由人决定，又决定了人。像亚马逊或者Google这样的优秀企业必须要有与其文化相适应的人员才能高效运转，尤其是亚马逊这种冲突性的角斗士文化，必须不断吸纳在竞争力上能够适应它的人（在国外，亚马逊两年内的流失率非常高）。我们在介绍亚马逊领导力准则时说过，亚马逊的领导力准则会用于人员招聘和培养。这是如何做的？
选贤育能（HireandDeveloptheBest）
领导者不断提升招聘和晋升员工的标准。他们表彰杰出的人才，并乐于在组织中通过轮岗磨砺他们。领导者培养领导人才，他们严肃地对待自己育才树人的职责。领导者从员工角度出发，创建职业发展机制。
最高标准（InsistontheHighestStandards）
领导者有着近乎严苛的高标准—这些标准在很多人看来可能高得不可理喻。领导者不断提高标准，激励自己的团队提供优质产品、服务和流程。领导者会确保任何问题不会蔓延，及时彻底解决问题并确保问题不再出现。
另一方面，在亚马逊的招聘过程中，会围绕领导力准则所要求的竞争力进行重点考察。
各面试官在面试后要在系统中详细进行反馈【注13】，这些反馈包含：
这里，我们看到亚马逊面试设计的两个特色。
就候选人的反馈而言，由于整个面试过程通常是在纸上进行编程，因此，面试官在录入反馈时需要将程序和问答细节都录入系统，这确实是一个不小的负担（通常会花30~60分钟），但也正是这个过程，使得面试官在录入的过程中能够再次审视候选人，尽量客观的对其进行评价。另一方面，这样的反馈工作也锻炼了面试官的分析能力，并对其面试进行快速反思，从而使得面试官能够更出色地完成未来的面试工作。
其次，BarRaiser的设定。BarRaiser是公司内部经过培训的一些特殊面试官，他们会作为第三方参与到整个公司的面试流程中，并且代表公司在人员招聘方面的长期利益，这种长期利益主要是来平衡招聘经理快速补充用人的短视诉求。在一个面试中，BarRaiser必须同意才能给候选人发offer。
BarRaiser是如何代表公司招聘的长期利益？在BarRaiser判断的过程中，他们需要考虑如下两个问题：
正如之前论述飞轮时谈及，BarRaiser就是推动人员能力持续优化的飞轮中的重要一环。通过BarRaiser的设定，亚马逊期望通过不断提升招聘门槛来提升整个公司的人员水平。整个面试循环如下图所示。
图5通过不断提升招聘门槛（HiringBar）来提升整个公司的人员水平
毫无疑问，亚马逊的整个面试过程是很繁杂的。但考虑到亚马逊招聘的主旨——HiringTheBest。这样的流程就显得稳妥而高效。
如果我们不假思索地将这样流程直接用于初创公司，那一定会遇到问题！当我最初加入某个创业企业时，拿着整套方法，期望通过叙事性反馈和基于反馈的debrief来提高招聘的质量，但经过几次尝试，HR和参与面试的人员就开始抱怨。稍作分析后不难发现，多数创业公司的用人诉求是快速找到能干活的人员，至于面试体系的优化、人员水平的提高或者人员长期的潜力都是次要得。在这种情况下，我们可以对亚马逊招聘流程进行一定的调整，形成一套适合自己的招聘体系：
通过前面的讨论，我们知道这些通过面试的候选人很大的可能性会契合亚马逊的领导力准则，优于该角色当前50%的人的能力，而且其潜力能够在将来对亚马逊产生影响，那么，在具体技术方面，亚马逊对技术人员有怎样的要求呢？这些要求又如何影响了亚马逊研发的效率呢？
SDE全称是SoftwareDevelopmentEngineer，他们是亚马逊系统的建设者，是技术研发的中坚力量。【注14】当我们探讨亚马逊对技术人员的要求以及研发效率的问题时，主要是针对这个岗位的人员。在我们具体看亚马逊对技术人员的要求前，我们先分析一下技术人员在亚马逊所面对的问题。
无论是#1~3这样传统的电商研发团队，还是之后更为技术性产品的研发工作，这些工作在当时（甚至现在）都是前无古人的探索，相应的，其技术团队除了了解其所面对的问题外——有时对问题的了解都是模糊的，很少有现成的东西可以参考。如此，当我们在技术岗位的JD上看到这样的描述就一点都不觉得奇怪了：
候选人能够独立地创造性地解决挑战性（模糊的）问题。
因此，亚马逊首先需要研发人员有解决问题的能力（ProblemSolving），而且还要快、能够独立完成。在2016的股东公开信中[15]，Bezos谈及High-VelocityDecisionMaking时谈到：
Day2companiesmakehigh-qualitydecisions,buttheymakehigh-qualitydecisionsslowly.TokeeptheenergyanddynamismofDay1,youhavetosomehowmakehigh-quality,high-velocitydecisions.Easyforstart-upsandverychallengingforlargeorganizations.TheseniorteamatAmazonisdeterminedtokeepourdecision-makingvelocityhigh.Speedmattersinbusiness–plusahigh-velocitydecisionmakingenvironmentismorefuntoo.Wedon’tknowalltheanswers,butherearesomethoughts.
从另一个侧面看，决策要快就意味着业务快，而业务快就要求支持的研发必须快！那么在业务驱动的大背景下，研发人员必须能够在信息有限的情况下和业务团队一起创造性的快速解决问题，这也是责任感的一种体现【注15】。当然，亚马逊的领导力准则仔细推敲起来就是要达到一种低成本、高质量的快速行动力。
再进一步看，当我们有一些想法，需要研发团队配合开发一些支持系统，以便整个业务能够运转起来。当业务运转起来以后，通过系统了解业务的运转情况，我们会有新的理解，而后就产生新的想法，研发了解并进行相应的开发，改进的业务运转起来。之后继续这样的循环……
这个循环让我们了解到第一个有关研发的事实：软件研发本质上是一个学习的过程，尤其是快速学习相应领域中的业务知识。我们对业务领域越是了解，我们开发出的系统就越简单好用。因此，亚马逊的技术研发人员必须要有优秀的学习能力，考虑到业务和技术变化的速度，研发人员必须有快速学习的能力。
再进一步看，当我们了解了业务并清楚需求后，我们要把这些业务需求变成运行的系统，这个过程要涉及一系列工作：
这些工作中，什么是最核心的？从业务的角度看产品设计和系统设计是最核心的，编码实现则更像某种翻译工作。因此，我们得到第二个有关研发的事实：软件研发本质上是设计。如果我们将产品设计的工作交给TPM（类似产品经理）或者PM（业务人员），我们可以将这个事实针对研发人员进行改写：软件研发能力最关键的是设计能力。
至此，我们稍作总结，亚马逊的SDE是什么样的人？
这大概也是你心目中对研发人员的要求吧？无论如何，我们在创业公司中是按这个要求寻找同行的小伙伴的！
为什么亚马逊内部将SDE戏称为啥都干的人（SomeoneDoEverything）？这可以引出亚马逊内部有关研发工作的两个有趣举措：
首先，我们来探讨一下人人都是架构师。
正因为亚马逊认为研发人员最关键的技术能力是设计能力，所以在岗位要求和面试安排上，系统和软件的设计能力都是关键点。比如，SDE1需要了解设计，而SDE2就必须能够独立地进行设计工作，到SDE3，需要把握复杂系统的架构。
当进入公司的研发人员已具备（或有潜力习得）设计和架构能力，并有问题解决能力，还可以深入细节、快速学习，此时，单独划分出架构团队的意义就不大了，而且一旦设置独立的架构团队则必然引入额外的沟通和决策过程，而且架构团队脱离具体的业务也很难给出适合的架构，这些架构团队就会成为高效研发的桎梏。近些年主流的看法是让架构师参与到开发工作中，也就是架构师要参与编码或者实际参与实现其架构。亚马逊的做法是从另一面入手，既然所有人都具备架构和设计能力，那么就让实际业务的开发人员做架构吧。
不可否认，即便对于亚马逊的研发工程师，架构工作仍然是非常复杂的。为了让开发人员能够真正担负起架构工作，一些措施必须就位来降低架构工作的复杂性。这些举措涉及：
稍后，我们将涉及这些举措，可以这样说，正是这些举措使具体的研发工作变得简单高效。在此之前，先让我们聊一下开发人员完成一切。
Thereisanotherlessonhere:Givingdevelopersoperationalresponsibilitieshasgreatlyenhancedthequalityoftheservices,bothfromacustomerandatechnologypointofview.Thetraditionalmodelisthatyoutakeyoursoftwaretothewallthatseparatesdevelopmentandoperations,andthrowitoverandthenforgetaboutit.NotatAmazon.Youbuildit,yourunit.Thisbringsdevelopersintocontactwiththeday-to-dayoperationoftheirsoftware.Italsobringsthemintoday-to-daycontactwiththecustomer.Thiscustomerfeedbackloopisessentialforimprovingthequalityoftheservice.
这段谈话给出让研发进行运营维护工作的好处：
JGLet’spostulatethatsomebodyhascomeupwithanideaandtheteamhasgoneoffandbuiltsomething.Howdoesthego/no-godecisiongetmade
WVItmaydependonthecriteriaforsuccessthatweredefinedupfront.Whentheserviceisreadyforbetatesting,wewillslowlyintroducethistoourcustomers,andthenwemeasurerelentlessly.
需要注意的是，虽然多数情况下，SDE会优先且尽力承担研发中涉及的所有工作，但当需要更强的专业性时，亚马逊也并不排斥在团队中设置相应的角色，并将工作交给他们。例如，服务供应商的SellerCentre系统，由于用户体验和交互对提高用户使用效率非常关键，因此，整个大团队会设置产品经理和前端团队。类似的，有些业务会需要数据工程师（DataEngineer）或者是嵌入式系统架构师（EmbeddedSystemArchitect）这样的研发人员，对这些人员而言，则需要学会这些支持性系统，有时甚至是必要的开发技能，以便在资源有限的情况下依然能够保证业务推进和系统的运营维护。
另一个比较容易引起误解的地方是对测试以及测试人员的定位和使用。毋庸置疑，测试是非常重要的工作，只是对大多数系统或服务而言，测试更多地通过自动化和程序性的完成，即便还会有一些手工验证的工作，这些工作也常常由系统的开发者内部消化掉。在一些强调用户体验和可用性的系统或服务中——如移动端应用，也会设置专职的测试人员。除了QA，亚马逊的SDET（SoftwareDevelopmentEngineerinTeast）是用程序来进行自动化测试的岗位。
近几年非常流行的全栈工程师在亚马逊内部并不会提及，既然亚马逊对SDE的潜在要求是一人多能——尽量独立、尽力全能（干），为了达成业绩（DeliverResult）什么都得学会，谁还会觉得多学一些东西是了不起的事情？毕竟，在这样的环境下，全栈只是全能的一种副产物！
在目前的创业公司中，我们尝试通过开源工具搭建出与亚马逊相对应的支持工具链体系，如下图，并让研发人员完成一切开发和运维工作。在近百人的研发团队中，我们只保留了两名传统运维人员来负责机器、网络等基础设施维护，而且完全没有测试人员。
在WernerVoegls的访谈中，老爷子轻描淡写说，“Thisbringsdevelopersintocontactwiththeday-to-dayoperationoftheirsoftware.”对于亚马逊的SDE，每天的运营维护工作可是很具体而且不那么让人舒服的……
不难看出，7x24的OnCall确实是个辛苦的负担，尤其是打扰到睡觉或私生活的时候，这个负担会尤其痛苦，但这也恰恰正是让SDE担负OnCall的有趣之处。当事情让人痛苦时，我们可以采取两种方式处理，一种是拍拍屁股走人，让问题变得更糟；一种是留下来咬着牙把问题解决了，让整个世界美好起来。显然，无论哪种职场鸡汤都会鼓励后一种行为。事实上，痛苦确实能够激发创新，要知道亚马逊的部署工具链和Google的应用运维系统都是在研发人员完全不能好好睡觉的情况下被现实逼着开发出来的！
Bezos要求：
研发团队需要在业务持续增长的情况下，系统每年的问题数量下降10%，相应的支持性人员（工作）要减少10%……
举个例子，如果团队有10个SDE，去年有1000个Tickets，那么今年系统Ticket数量要在900以内，而且还要解放出一个SDE，这样团队就可以用同样的人负责更多业务，如果业务没有明显增长则可以缩编。这里10%是一个用于参考的底线值，通常团队会根据自身情况设置一个相对合理的值，如果数值低于10%或者无法完成，这种特例需要上报到高层管理批准。由于OE目标是来自Bezos的要求，而且还作为各级管理者绩效考核的内容，因此，系统问题的数量、趋势，以及严重问题的事后分析会被每周的管理会议过问。
亚马逊的事后总结与分析的方法称COE（CorrectionOfError）。其通过识别问题的根本原因并追踪识别的行动项来解决这些问题，从而提高服务（或系统）的整体质量并推进负责团队的责任。需要注意的是，COE不是寻找问题责任人并进行处罚的过程！
COE在形式和作用上类似GoogleSRE的事后分析，内容包容如下部分：
总结一下：
让研发人员直接负责在线报障可能是快速提高业务服务水平和系统质量的最好方法了。我曾在两个创业公司内尝试建立由开发人员负责运营维护并进行7X24OnCall的制度。在第一家公司，其后来负责研发的老大认为应该保护研发团队——运维的痛苦应该找专门运维的人员来负责，最后，系统中的问题总是周而复始的重复出现。在第二家公司，我们为此建立了整个流程和支持工具，如下图，效果真是谁用谁知道！
OneofBezos’smorememorablebehind-the-scenesmomentscameduringanoff-siteretreat,saysRisher.“Peopleweresayingthatgroupsneededtocommunicatemore.Jeffgotupandsaid,‘No,communicationisterrible!’”Thepronouncementshockedhismanagers.ButBezospursuedhisideaofadecentralized,disentangledcompanywheresmallgroupscaninnovateandtesttheirvisionsindependentlyofeveryoneelse.Hecameupwiththenotionofthe“two-pizzateam”:Ifyoucan’tfeedateamwithtwopizzas,it’stoolarge.Thatlimitsataskforcetofivetosevenpeople,dependingontheirappetites.
其一，当业务系统按功能（或具体业务）分配到2PizzaTeam时，其所能处理的问题规模和复杂性将是有限的，同样的，团队所要面对的架构问题的规模和复杂性也就相应的降低了——这正是探讨人人都能做架构时，我们说的通过团队划分来降低问题规模。
其二，当人数变少后，官僚主义就很难发展起来，整个团队更容易形成积极、自治的氛围。这也不难理解，在一个结果导向的角斗士文化氛围中，如果有人混或搞权谋的话，团队就很有团灭的风险——不管你是不是自认为做了正确的事情。
以下是来自网络的一幅图，大致描述了亚马逊转变后的组织结构。
这样的划分使技术团队能够专注解决对应业务的问题，或者说这是业务驱动技术在组织结构上的体现（或者说业务优先）。由于此时团队规模通常在7+/-2人，所以一般不会有特别复杂的工作，而有关业务的设计决策将在团队内部消化。这样划分的另一个好处是技术人员，尤其是技术团队的领导，会对业务非常熟悉，因此，一些业务团队的高层领导（Director和VP）都是从技术线上去的！
但一个具有挑战性的结果是团队增多，一个业务性的需求可能需要不同的团队配合才能发挥作用，此时团队的协调将是一个问题。亚马逊是通过计划流程（OperationPlanning）来帮助团队在战略性层面解决工作安排的问题，我们随后讨论。现在，我们先看看技术团队和业务团队要如何合作？
如上图，技术团队和业务团队的合作并非经由上层协调，双方主要的沟通都是团队之间直接的水平的沟通，也就是说，在基层，需求、问题和日常交流都是由业务团队直接反馈给技术团队的负责人。另外，在各个层面上都会有对等的水平沟通，向上的汇报机制主要用来反馈问题或者汇报业务进展情况。
无论是团队层面还是公司层面，产品和功能要进入开发前必须回答下面这些问题：
在实际执行OP1和OP2的过程中，业务团队仍然会有临时需求，甚至是自上而下来自Bezos的需求。这些需求（除了Bezos的）都会由业务和技术团队沟通，并依据其业务价值来与OP上的需求进行比较，进行计划的调整。
亚马逊的计划过程并不适合创业公司，但具有启发意义：
我们已经谈及通过组织结构层面的调整来简化架构的复杂性，也了解了通过工具和服务封装支持性架构和开发运维工作来降低研发工作的复杂性，接下来我们看看架构工作是如何在研发人员之间分配的。
亚马逊有一个内部文档，其详细地列出SDE1到SeniorPrincipal各级的软技能和硬技能的要求，以及从一个级别到更高一个级别要做的事情，以便研发人员自行对照修炼。如下图，我们简单地分析了各个级别所属团队、共享情况、职责和影响力。由于亚马逊没有专门的架构师团队，而且亚马逊期望所有人都能进行架构工作，因此，越高级的技术人员就需要尽可能在这方面发挥更大的作用，可以说能力越大，责任越大。虽然SDE3以上的研发人员需要隶属于某个业务部门，但他们已经是某种程度的共享资源，其工作安排的顺序是从部门内到部门外。虽然其工作重心可能不再是专门实现小团队量级的业务需求，但其依然会参与其中，尤其是在关键项目的攻坚上。对于Principal，他们常常会做一些前沿性的探索和开发工作，比如，AWS上无比好用的SWF（SimpleWorkflow）就是一个Principal带领SDE3做出来的。
对于设计评审，现有功能的扩充通常不需要进行设计评审，新功能的设计评审通常在团队内部完成。当涉及的业务影响比较大或者技术上有一定的挑战时，团队经理会在本部门内（通常是沿组织结构向上）寻找高级别的技术人员对设计进行评审，偶然也会跨部门找某些领域的专家来进行评审。虽然偶尔需要刷脸或者需要更高层面的管理者介入协调，但研发人员通常是比较热心的——一封言辞真切的邮件就足够了，再者，作为亚马逊人，在Ownership的名义下臭不要脸是必须的！
日常工作中，还有几个角色常常与SDE打交道，他们是SDM（SoftwareDevelopmentManager）、TPM（TechnicalProgramManager）和PM（ProgramManager），亚马逊对SDM和TPM有技术性要求，也就是说，他们需要懂编程和设计，所以，当你在亚马逊办公室漫游时，看到一个SDM抱着一堆AWS产品的技术说明文档啃，这是一点都不奇怪的，因为他们要上云了。
亚马逊的SDM首先是PeopleManager，还是ProjectManager，甚至有时还要做ProductManager，这也算是一人多能的表现。对于TPM，具体看团队的要求，他们通常是懂技术的ProductManager——会画原型，有时会做ProjectManager——可以帮助团队识别被依赖的团队，甚至和这些团队确定接口细节，以及推进项目前进。
PM就是我们常说的业务人员，这些人常常可以自己根据需求画出产品原型……
架构工作的一项内容就是对不同解决方案的进行选择。这种选择即可能涉及业务层面，也可能涉及技术层面。系统的架构更多是技术层面上的选择。不难理解，技术层面的某些问题具通用解决方法，相对应的，这些方案就成为一些固定的（或推荐的）选择，如下图所示，这些方案在专制水域。经验告诉我们，专制带来效率上的优势，但同时抑制了创新。那么，在一个公司内，如何让这样的选择简单高效，但又不会抑制创新？
在公司范围内，亚马逊对一些关键的技术架构做了强制或推荐，比如，RPC必须用Coral，定时任务应该用DJS（DistributedJobScheduler），工作流推荐用SWF，消息中间件推荐SQS等等。有时，同样的问题可能会有多个框架在专制水域，它们各自可能对某些特定情况有更好的表现。
相对应的，在各团队内部，其系统所用的语言、框架都可以自行确定，甚至对重新发明轮子也会足够宽容。但如果系统的影响较大，而且使用了非推荐的技术，那么在设计评审时就必须用证据来说服参与的人员，尤其是那些高级别的SDE——他们经常会问为什么不用某某已有的技术。某些情况下，当某个团队的某项工作被证明有更为广泛的影响时，这些工作会从民主水域上升到专注水域，成为公司范围内的推荐解决方案，比如，SWF最初只是一个Java的库，后来在业务中被证明可以极大地简化开发工作，其不但成为AWS上的服务，还成为公司内工作流推荐解决方案。
亚马逊一直重视知识的积累和共享工作。这里我们简单地介绍一下：
由这些工具还可以看出亚马逊对代码的态度，除了某些关键性项目，亚马逊并不限制员工查阅和学习其它团队的代码。从某种意义上看，亚马逊对数据的态度则更为严格，曾有浏览核心数据直接走人的先例。
另一点就是，支持性工具始终处于不断演化的状态——内部支持性系统和工具也是这样，随着规模扩展，更高效和易用的工具会被创建以便提升研发人员的效率，比如SimpleSearch，在12年左右推出，可以同时搜索亚马逊内部3个主要的知识库。
最后，亚马逊无论业务和是研发，其对工具和自动化有着与生俱来的痴迷。根据不完全统计，其内部用于研发和管理的工具总计有近50个，这些工具多数是自研的，而且多数都在日常工作中使用。
“Iamemphasizingtheself-servicenatureoftheseplatformsbecauseitisimportantforareasonIthinkissomewhatnon-obvious,”wroteJeffBezosinhis2011LettertoShareholders.“Evenwell-meaninggatekeepersslowinnovation.Whenaplatformisself-service,eventheimprobableideascangettried,becausethere’snoexpertgatekeeperreadytosay,‘Thatwillneverwork!’GuesswhatManyofthoseimprobableideasdowork.”
亚马逊的研发有什么特点呢？
行文仓促，还有一些话题没有涉及，有一些也没有深入，如绩效评价OLR和DogFight、EngineeringExcellence、工具链等等，期望未来可以更深入的思考和总结。
亚马逊有一个内部宣传标语：“WorkHard，HaveFun，MakeHistory！”。我们常常调侃说只需要WorkHard，其它两条可以忘记。但离开亚马逊两年后，却发现亚马逊对自己的历练和改变如此巨大……，最后，以《TheEverythingStore》中的Bezos的话纪念我和一帮前同事在亚马逊的日子：
你可以超时工作、勤奋工作、动脑工作，但在亚马逊，你不能三选二。
注1：由于自2015年，亚马逊开始连续盈利，这样的质疑声已不再，现在没有人怀疑亚马逊是21世纪的商业巨人（thetitanoftwenty-firstcenturycommerce）。
注2：Bezos和Jobs都是臭名昭著的坏老板，属于经常咆哮（yelling）和羞辱下属的人，请从以下金句中领会[3]：
注3：Rossman在这里解释了飞轮中的Growth部分，这源自Bezos对互联网的判断，他认为“it’sstillDayOneoftheInternet”，“theInternet’spotentialforgrowthisgargantuanandstillfundamentallyunexploited”，因此，“Sohe’sreadytoslashpricesandcreateprogramslikefreeshippingtocultivatecustomerloyaltyanddrivesalesgrowthtowardtheunimaginableheightsheforesees.Thenheinveststherevenuesgeneratedbackinto“theholytrinity”:price,selection,andavailability”
注4：复杂的商业系统背后，其本质往往是简单的，只有骗局才故作高深并且无比复杂；与之类似，研发体系的整个基石梳理到最后往往也很简单。这里所谓的复杂是指complex，比如，供应商入驻过程会涉及十几个系统的对接，其过程可以说非常繁杂（complicated），但其原理却并不复杂（complex）。
注5：所有的公司都有企业文化，最不济也是老板文化！
注6：不要以信众的数量来评判一些互联网大V言论的正确性，因为萧伯纳说过，“瓜怂虽傻，但还有更傻的‘瓜怂’为其喝彩！”
注7：这也提醒我们独立思考的重要性，尽信书不如无书！
注8：国内有个定期刷屏的类似理念——人品比能力更重要。
注9：JohnRossman在《TheAmazonWay》[4]中则将Bezos的性格特点与亚马逊的领导力准则（LeadershipPrinciple）建立起对应关系。
注11：国内的互联网媒体上经常刷屏的一个流行词就是不忘初心，我觉得Bezos在行动上算是这方面的典范，每年的致股东的公开信都要附上1997年的股东公开信。国内马云也是有心人，你今天都能看到当年马校长推销中国黄页的视频。各位，买好录音笔和摄像机，用得上！
注13：面试官在完成自己的反馈之前是无法看到其他人的反馈情况的，这样做避免了面试官之间相互影响判断。
注15：在互联网高速发展的大背景下，一切都需要快起来。国内有两个类似的理念，一个是互联网唯快不破，另一个是这两年流行起来的搞定，这个搞定其实就是问题解决的能力、责任感与执行力的结合。
注16：我第二喜欢的胖子，我技术上的精神导师……
注17：ABB代表如下系统：
注18：由于亚马逊业务上的诉求更重要而且更频繁，相比较，高并发和稳定性这样的要求只有极少数面向大量用户的系统需要，如Retail网站，因此，Google的SRE制度是不可能从亚马逊这样的公司产生的，而且当Apollo和Coral这样的系统和工具就位后，大多数高并发和稳定性的问题的处理会变成简单的操作性问题。在资源维护的层面，亚马逊应该有类似GoogleBorg这样的分布式资源调度系统，不过从应用开发和维护的角度看，在系统云化后，这种调度反映出来的服务就是ASG（AutoScalingGroup），至于资源的切换和物理机的管理，对SDE则是完全透明的！
注20：传说中，2002年，Bezos给全公司发了一封信，吹响了整个架构演进的号角：
注21：这里会有看似的特例，比如负责内部支持性工具开发的组应该是隶属于EngineeringExcellence的，但其实他们的业务就是服务内部开发。
注22：显然，亚马逊并不在意你的工作和生活的平衡，它只是尊重你的想法和工作成果，当然一切看结果。