Background
离开Amazon之前我的大老板跟我做了一次Skip Level的交流，所谓Skip Level就是直接跳过你的直属上级，跟他的上级进行交流，在国内的互联网公司很显然是没有这种模式的。这次的交流也总结了很多经验。
面对员工的离职，总是有这样那样的原因，但对于一个团队来说，从这些离职人员口中得到他们真实的痛点以及不便言说的苦楚可以使团队得以继续健康、稳定发展，可见这次谈话大Boss也是诚意十足。 一般离职员工和直属上级之间由于工作关系和人际关系等因素，可能并不会掏心掏肺的说一些真实原因，总会说一些场面话。
What’s Good
在Amazon感受到比较好的
-
定期的技术Session交流 这一点做的很不错，我印象中除了入职初期Team内各自身员工（主要是SDE3和组内的SDE2）会对整个业务和工作模型等做讲解和梳理。
-
比较好的沟通机制 和直属Manager之间会有定期的1:1，一般都是一个月一次，时间大概一个小时左右。谈话的目的主要包括对现有工作的安排以及完成的情况，以及对团队的问题的指出和提出改进意见等。
-
？
What’s not Good
工作机制
我们团队主要使用Scrum的方式进行开发，每天都会有站立会同步各自的进度，时间虽然不会很长，但是有时候觉得其实真没什么可以说的，可能是频率太快了。 另外对于Track大家的工作我们采用的是Sprint，这个东东非常的好用——起码对Manager 来说是这样，我们的任务会被细化到每半个小时的基本单位，任何一个工作超过半个小时都会在这里记录并要求随时扣除已完成的时间以便可以查看本周的进度。在每个礼拜的周五都会集体开一次所谓的Sprint 会议，大家围坐在一起，Manager一个一个的校订每个人的任务的完成和用时情况，如果你的耗时超过了预估的时间，需要做好准备如何跟Manager 解释。这一点其实很容易让人诟病，主要原因是提前一周做好下一周的Sprint 计划其实真的不是很有效，很难预估的很准确，基本上都会评估的用时少于实际耗时，如果你问为什么不多估一点，那你需要做好被Manager Challenge的准备。
Disruption
这里说的是Ad-Hoc的任务，比如Manager可能随时转发一个邮件过来让你完成一个数据的处理或者一个并不是那么容易做的「小Task」，其实这些东西可能又费精力又难搞，且时间完全不可控。 如果你每周都会有这样的工作，其实对SDE的工作内容和工作方法干预较多，容易打乱节奏和影响心态。
Disadvantage
由于这一点是Amazon的Principle之一，所以特意说一下，其实在跟强势的Manager沟通的时候真的很难有Backbone，尤其是一个懂技术的Manager ，他不仅习惯站在你的角度思考问题，替你做工期评估，而且还由于其具有更专业的知识和先发的信息掌控优势，导致SDE在沟通和讨论中越来越被动。所以SDE天然就处于劣势的位置，如果恰好还是个内向的SDE ，基本上就是「逆来顺受」了。
- 没有足够的buffer来消化和深耕一些东西，如项目背景、代码review和技术栈的培训，项目庞大，细节多，复杂，很难掌握whole picture，却常常需要频繁的被“赶鸭子上架”
- ？
Ownership
这一点特别指跨团队沟通时各个团队之间没有形成良好的互助协作的氛围，导致个人只对组内（特指Manager）负责，对外没有动力和足够敬业的态度来处理Cross-Team 的问题，沟通效率低，事情推进也慢。
Inheritance
团队越来越大，项目越来越多，但很多工作和项目都缺乏足够详实的wiki，这样容易导致组内的技术财富和知识背景都不能很好的传承，导致新人和老人之间存在知识断层，反过来会影响SDE的工作，容易 让其产生慌张感。
本文首次发布于 LiuShuo’s Blog, 转载请保留原文链接.
