这个从车库起家的公司虽然搬进了大楼，但把车库中的一些东西也一起搬来了。
比如亚马逊早期创业时昼夜编码开发，为了省钱临时用门板拼装成了桌子。这样的桌子就是要告诉工程师：我们和那些不差钱的高科技公司不一样。别忘了苦日子，艰苦奋斗，居安思危！
这是做戏还是来真格的？
很快入职的亚马逊新员工发现“葛朗台”在亚马逊根本不是一个贬义词，这家公司开大会不摆矿泉水，一律自带。
据说亚马逊十四条领导力准则里有一条就是勤俭节约，力争以更少的投入实现更大的产出。改装风格的金属片。
2.亚马逊奇葩的文档文化
亚马逊的工程师写文档么？写，而且还大量写，但是不写PPT。写作在亚马逊是必备的硬技能，研发团队也不例外。亚马逊内部最常见的就是6页纸文档（
6 pagers
），工程师的架构设计就属于这类正式文档。
刚加入亚马逊的工程师往往不习惯：“要我写上几千行代码是小菜一碟，要我写上一页文档简直要命。”有人干脆就画了个架构图，再附上一点接口定义敷衍了事。
结果第一次的设计评审往往成了“批斗大会”。
那么亚马逊真的没有任何PPT么？也有，但是大都很蹩脚，并且大家不把PPT当回事。见过最奇特（
葩
）的PPT来自一位高级经理。十几页幻灯片都是白底，每页上只有一个数字。
他对着这个PPT讲了20分钟，基本都是这样的话：
“1.25，这是我们新系统上线后节省的成本，在过去的1个季度，我们一共节省了125万美元。”
“2300，这是我们的新SLA，从检测到仓库中发布的进货消息，经系统处理后更新到ElasticSearch的索引，到可在前端被用户搜索出来，我们从过去的4000ms提升到了2300ms，这里还有很大的改进空间。”
3.亚马逊工程师的oncall文化
在亚马逊，要求技术团队的工程师必须是全栈的。亚马逊没有前端工程师、后端工程师、运维工程师这类划分。统一叫做
SDE
——Software Development Engineer。有人将其戏称为Somebody Do Everything。
做一个项目，一个工程师通常从前做到后，从界面做到底层。不仅上线功能给最终用户（
买家或卖家
）使用，把数据导出到业务部门的集群上做商业分析，并且还要开发出供内部仓储物流工作人员使用的工具。
很多情况下，工程师懂技术还不够，还必须完全了解业务部门的细节。
比如FBA（
Fulfillment By Amazon
），工程师们对于现代化物流仓库的设备和流程要了如指掌，看到一个包裹上的条码，就能够如数家珍的说出这个包裹是否是亚马逊自营的、是否是合作伙伴负责物流的、是独家专卖还是卖家混卖的。要能够很快找出这个包裹是自动收货的、还是人工收货的、是亚马逊打的泡沫包装还是卖家自己做的……
——看到这些内容，做hrbp的伙伴好好思考一下吧。
1.亚马逊商业模式——
“飞轮理论”
以飞轮带动规模成长，构建“大体量低利润”的竞争壁垒。
亚马逊底层的商业逻辑是飞轮理论，支撑亚马逊飞轮的是客户体验的三大支柱：
相对的低价、丰富的选择和便利
。
首先找到了一个低成本的结构，这个结构是从商业模式、运作效率和管理方式来看都是低成本的，于是能提供低价格，高体验的产品，然后去获得海量的用户，进一步降低它的成本，降低它的价格，获取更多的用户，然后让批量变得越来越大，然后让竞争者进入的壁垒越来越高。
2.
亚马逊组织能力——“核心业务自建，以并购及合作加速飞轮”
亚马逊的组织能力似乎是没有边界的，从一开始的电商起家，然后到发展云业务，如今边界越来越广，做数字内容。
其核心业务里大部分都是自建，在内部催生孵化，但也会通过收购来补充能力，以地区合作机构和开放平台生态伙伴的形式进行合作。
亚马逊真的正在系统性的把整个公司产品化，打磨那些被证明可行的业务，修补那些高潜力业务，再砍掉其他没什么意义的一切。
亚马逊人坚持其实的是以客户为中心，无论你是什么，在我的眼中，都是我的客户，并把这个正确的道理坚定地做下去。
3.亚马逊业务团队——“稳定的业务架构”
亚马逊的组织架构有三大特点：
① 亚马逊对组织架构概念比较弱化，架构调整频繁，基本基于贝索斯的关注；
② 各大业务板块互相相对独立，类似事业部制，职能闭环(
包括产品、研发、销售、市场等
)；
③ 强总部定位，核心产品及研发集中到总部，后台职能由总部统管，定向支持各个业务，区域偏执行层面；
而其中也有比较有意思的点，例如亚马逊里的
jeff
特别多。
另外，亚马逊似乎就是个神秘组织，其中的编号毫无意义，编号只是为了掩盖它背后做的事，很多之前创新的成果都是通过这种乱七八糟命名的独立组织来隐藏目的。
4.
亚马逊创新机制——“通过管理手段覆盖完整创新矩阵”
亚马逊有一个完整的创新的矩阵，里面所涵盖的各种类型的创新要素，都能够通过他的管理手段去覆盖，有自上而下的创新，也有自下而上的创新。
一方面并不是贝索斯完全高瞻远瞩，打一个准一个，大量创新其实也是失败的；另一方面，也不是想法不断地从下而上地涌现出来。
每一个员工确实可以通过叫
PRFAQ
的工具，直接把自己的想法
word
文档转成
pdf
，可以不通过直线
manager
而直接发给任何潜在的
sponsor
；
但同时，亚马逊其实也有非常教条式自上而下的创新方式，就是
E-Staff
团队
.
E-Staff
团队可以理解为亚马逊的总办是非常稳定的。
其中每个人，每个季度要给贝佐斯讲一个
PRICQ
的新的点子，而且不能是现有业务的改良，而这个团队的成员也会把任务目标分解，让下面的人提点子。
所以在这些管理者的脑子当中，他是被两个
pipeline
来去驱使的，一个
pipeline
是他
idea
的
pipeline
，另外一个
pipeline
的话是对人才的。
用新的人才带来新的创意，用新的人才去实现新的创意，用新的创意去驱动整个组织向前发展。
亚马逊内部就是通过两个
pipeline
来解答这个问题，通过项目的流转，人员的流转，来去缓解这个问题，他并没有最终解决掉这个问题，因为管理做出来的本就是一个优先级的判断和决策。
5.
亚马逊小团队——“根据目的不同，构建两个
pizza
能喂饱的小团队”
典型的亚马逊团队中包括几名工程师，搭配一个产品经理和一个设计师。而亚马逊团队的构成体现了他们的两个理念，一个是团队大了任务自然能分拆，另一个是找对的人组团做专门的事。
亚马逊的团队会有以下几个特点：
①
人数要少：常见的亚马逊团队规模是
4-14
个人；
②
功能闭环：要做出一个原型的话，需要方方面面的精英，不会全是设计人员或开发人员；
③
单线汇报：团队主管对负责的业务享有充分的话语权，团队成员直接向他报告；
④
关注点单一，分解为原始问题：团队思考的是那些最终极的最想解决的问题，把问题分解，做得纯粹；
那团队这么小，怎么能很好地解决挑战性较强的任务呢？其实是需要有非常强大的底层技术平台的，可以说技术是亚马逊创新的底层引擎。
贝佐斯秉持着以技术驱动的理念，认为几乎所有的问题，都是技术问题。
所以整个亚马逊会通过很多技术的手段，去解决人性和管理中的问题，所有业务都在思考如何通过软件使客户体验更好，尽量去自动化地做事。
其中
AWS
提供菜单式地微服务（
Microservice
），内外部客户都可以灵活调用，所以
AWS
能作为内部创新技术的“资源池”。
1.
亚马逊的招聘配置——“标准统一、流程简化，运用
Bar raiser
机制”
亚马逊的招聘标准极其统一，用表现和资格两个硬性标准进行，同时非常注重新员工对团队会有长期的价值贡献。
面试的过程中，每个面试官会被赋予不同的领导力原则问题，一条一条地卡候选人。
另外，亚马逊会有独特的
bar raiser
机制，如图所示。
这个人就像是个卫道士，是“阿岳真的很严格”的这种人。在最终评定的环节面试官会一起讨论，
bar raiser
和
heavy manager
都具有一票否决权。
至于亚马逊的人员配置，整体员工会分为
12
级，
4-6
级的员工比较多，结构相对扁平。
这其实也跟美国的职场环境有关，大部分美国的员工，在整个职业生涯中，可能就是两到三次晋升机会，一部分美国人其实是抗拒晋升的，因为会涉及到更多责任，更多压力，还要背更多绩效。
2.
亚马逊的绩效考核——“基于
360
度考核法进行绩效考核”
亚马逊的全员都以
360
度绩效考核，没有具体的团队考评，而团队绩效的评定就是对该团队
leader
的绩效评定。
亚马逊认为群众的眼睛是雪亮的，应该提供更多的反馈跟支持，让整个绩效评估的结果尽可能全面和客观。
在考核方面，每年
