我在Facebook学到的10个经验
1、坚持你的远景，但要对细节灵活。
作为一个领导者，你需要依赖你自己的远景（至少在你负责的业务领域内）而那些和你一起或为你工作的人将依赖你的远见。什么是远景？就是对最终状态的一种描述。是你需要你的团队着陆的地方。是生效之后的新生活。它是北极星，和方向。这里有一个例子，当我启动支付风险团队的时候，我们只有规则引擎。规则是人写的。一条规则只是一个拥有非常有限变量的简单逻辑，例如“如果注册日期少于30天并且支出大于100美元并且是首次支付并且用户来自印度尼西亚，则拒绝交易”
人类难以有效的处理10个以上的变量。我们需要更加的可测量化。我们想要使很多机器比人更擅长的事情自动化。从而我们树立了一个远景，将我们主要的规则置换为机器学习模型。这一远景驱使我们增加了一位机器学习领域的博士和另一位在加入facebook以前有类似实操经验的工程师。赌注巨大，但是未来需要这个。
但你需要对细节灵活，因为条条大路通罗马。你需要给你的团队以足够的余地空间（wiggle room），只要你的团队是朝着正确的方向以合适的速度前进。另一个故事：一度我对决策树的兴趣比回归要大。但是实验算法的工程师告诉我在选择算法的时候他们只有可以忽略的区别。我可以坚持己见（这确实是当时我真实的想法）但我信任他并让他放手去选合适的算法。同设计者合作的过程中也有趣事发生，他们对于字体，颜色，行距及其他都有着吹毛求疵的偏好。我通常让他们由着性子只要对最终结果有益就行。我们想要选择正确的战场开战，这样的战场必须关乎全局，而不是纠缠于局部战斗。
2、只和最好的人合作。
牛人只想和牛人一起工作。他们聚在一起就更牛逼。一流的人通常无法容忍二流货色。什么决定了“最好的人”？我的理解是那些能够快速尽其所知，学其所不能，从而完成事情并远超期望。他们的本能是超越期望，甚至他们自己的期望。对他们来说，足够好本身从来都不够好。只拥有最好的人在团队中有很多好处。
⑴这让你更加愿意托付。救我的经验来看，牛人不会信任不熟悉的人。在接受你的帮助之前，他们需要知道你同他们一样出色甚至比他们自己还强。否则，他们宁愿尽其所能的独立完成。但如果你业已得到证明，他们将会非常信任你并乐于托付给你。一个有着有效托付的牛逼团队几乎无所不能。
⑵他们相互为榜样，并且籍此提升工作表现。这是很好的关注压力。如果使用得当，可以形成团队的良性循环。
⑶牛人们相互挑战。我记得一位工程师主管曾就我们能否在规定时限之前完成网站翻译所需的代码修改来打赌，他将把头发染成蓝色。这样的挑战往往是的“枯燥”的工作变成了游戏。成为游戏的一部分将非常有趣。当然往往会有更严肃的挑战，而且牛人喜欢挑战（不管是挑战别人还是接受挑战）
⑷牛人们相互学到很多。如果不是因为这里有这么多可以学习的话我不会在facebook呆4年。对缺乏经验的人来说，这显得越发正确。我们雇佣非常聪明的毕业生，这些人被激发来证明他们的牛逼之处。他们不愿来到一个舒适并且没有挑战性生活的公司。他们想学很多来丰富他们的经验，完成不可完成的任务并提升他们的职业路径。他们想要证明“是的，他们可以”。他们想和牛人一起来实现这些。
你不想要二流货色但如何远离他们？首先，慢点招人。在给offer的时候固执一点。我曾无数次的在招聘决策会议上发现那些有着光辉履历的人无法得到雇佣只是因为某个面试官觉得这人无法给他以深刻印象。在其他例子当中，那些获得一致通过的候选人仍然无法获得雇佣机会因为每个人都只是觉得他将将符合要求而已。在雇佣问题上，绝大多数情形下，你要风险规避。（顺便提一下我们也会雇用那些没有全票通过的候选人，只要有一两票强烈推荐﹣你将乐于在信任你员工的问题上冒险）其次，炒鱿鱼要快。让二流货色存在就像服用慢性毒药。一天一点，逐渐但终究你会为此挂掉。你要紧你所能的把二流货色踢到鱿鱼轨道上（在某些情况下，法律不让你这么做）我见过一些慢吞吞的鱿鱼，那对团队造成的负面作用可不是闹着玩的。
3、树立高期望并且衡量之。
作为领导者，你需要设定高但现实的期望。足够高使得你的团队不会感到无聊。现实使得他们不至于油尽灯枯。你要给他们创造一段经验使得旅程结束回顾时，他们会说：妈的，我都没想到我居然做了这个。这个*了。在Facebook，象其他硅谷高技术公司一样，期望同回报相结合，因此树立明确的期望本身就至关重要。并且你需要找到一个不容争辩的途径来衡量期望。我花了大量时间来和团队一起描绘我们在下季度里最重要的3-5个目标。目标被分别委派给单个或一组分工不同的攻城狮，或者被他们抢走。在这一情况下，我们不仅有一个由3到5个衡量指标组成的名单，使得我们可以籍此快速地说出来我们在干嘛，同时也知道每个具体目标后面是谁。团队的成功同个体表现息息相关。例如，我当年团队最大的贡献是在一年时间里，通过每季度不同的指标，最终降低了信用卡支付争议率75%。
有一点要强调的是﹣你还是要现实。在你只有10%的市场份额的时候却幻想10几倍的收入增长无疑不现实。史蒂夫乔老爷非常善于推动他的团队超越潜能但同时也榨干他们（尽管如此他们是这样为他们所做的而自豪）99。9%的领导不是乔老爷，当然他们也不需要是。但你仍然可以通过驱动一个可持续性的团队来取得成功同认识到他们的极限并无矛盾。
4、倾听数据但不要单纯依赖之。
决定产品方向时，要的是想象力，激情和胆量，而不是数据。数据能让你的团队沿着正确的方向前进而不出轨，也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型。但数据不能帮你决定方向。举个例子，当我们在人工智能（机器学习）上压上我们团队所有的资源的时候，我们忐忑不安。但是我们坚信一点，现有的基于人工规则引擎的防欺诈系统会很快成为死胡同，因为它太死板而且不易规模化以处理大数据。所以，就像在电影指环王中Frodo明知通向Mordor的道路很黑很冷很危险，但那是一条他必须要选择去走的路；我们选择了在机器学习上压上所有的宝。失败，整个团队会很难看；但我们决定走艰难但我们认为是正确的路。这种思路同样应用在如何设计用于用户报告（外部工具）和案例审查（内部工具）的工具来应对潜在的欺骗行为。我们最后决定的方向是”进行自动处理”和”建立反馈机制”。直接抛给人工来处理总是很容易被选的一条路，因为只要建立一个人多人傻的客户支持团队即可。Lame！我们希望通过自动处理来解决大部分的欺诈案例，而把精力则放在那些确实需要单独处理的特殊案例上，同时把从业务支持团队（即客户支持部门）的处理意见自动采集并集成到下一轮的机器学习中去。由此，我们的机器判断会越加精确和聪明且与时俱进。
但你不能忽视数据。没有数据的支撑而一味靠直觉走黑路，很容易走岔道，甚至大错特错。有一段时间我们认为爬行工具（通过分析关联的cookie，信用卡）可能可以找到很多欺诈的同伙。通过实验结果却发现，这种预期是否成立很大程度上取决于当前流行的欺诈行为的特点。比如，当失窃或贩卖信用卡的案例非常普遍的时候，关联分析是一种有效的方法。但如主要情况是帐户被黑或小宝们冒用妈妈的信用卡去网游消费时，关联分析就作用不大。直觉在现实前面碰了一脸的灰。不过幸运的是我们很快意识到这点且把这个项目叫停了，所以没有浪费太多的资源。
另外，顺带提一下A/B测试。A/B测试并不会告诉你去做什么产品，但它可以帮你确定实现产品时的哪个细微版本更能揪住用户大爷们的心。
5、远离时间吞噬者。
刚进Facebook做工程师的时候，我非常享受那种日夜泡在码海中的感觉。后来慢慢的承担的项目责任越来越大越来越多，写代码的时间越来越少（但绝大多数时候仍占大头）。有时候更多的是把时间花在决定产品的方向和设计上。很多事情是和产品经理设计人员一起搞的。但在Facebook攻城狮们有很大的发言权甚至有些时候是拍板的权力。Facebook希望攻城狮们有王者风范。Facebook希望攻城狮能决定自己要做什么应该做什么，而不是总是”被决定”做什么（一种流行的说法是，write your own job description）。因此，我花了大量的时间在思考这些问题–哪些功能需要添加，哪些功能需要删掉，需要开始或停掉哪些测试，我们正在流血流汗的是不是现在最最最重要的问题，我们是该花时间优化用户交互流程呢，还是减少出错率，还是让系统更快，等等。这些问题很伤脑筋，答案经常不确定，比一个劲码到手抽筋要难。但这些问题很重要，甚至可能决定了你熬的日日夜夜究竟有没有必要。建议所有的攻城狮思考思考代码之外的这些问题，团队领导者就更有必要了。当然，攻城狮的大多数时间还是应该花在代码上。
那究竟哪些时间不应该被浪费呢？
很多，但我只举两个我认为最重要的例子。
邮件。不是所有邮件都发而平等。有些邮件纯粹打酱油的。有些邮件是不需要马上处理的。我尝试使用过滤规则来踢掉打酱油的邮件，突出需要马上处理的重要邮件。对此，分享两点。
（1）建立一个适合你的邮件过滤系统。我会对重要和紧急的邮件做即刻回复，而暂缓处理那些可以等到晚上再回复的邮件（尤其是发自我自己的团队，产品经理，兄弟连和顶头的不顶头的上司们的邮件）。但是，我要确保在我挣扎的爬到床上之前，把这些邮件全部处理掉，读的读，回的回。对于那些仅供参考的邮件，过滤系统会将其塞到某个固定的角落，我隔三差五去瞅瞅。此类邮件诸如某酒鬼询问NapaValley哪个酒窖比较正点等等。这些邮件通常比较有趣，挖的坑很大很深所以也很耗时间，我通常不跳或者不马上跳。
（2）广而告之你的个人邮件处理策略。我让我身边的战友们知道我是如何处理邮件的，并把这个政策放到我所有的邮件末端。如是说–“正在尝试个人邮件处理策略-为了戒掉Email瘾，我将强迫自己每隔三小时或以上查看一次Email，急事请电话/短信/IM我”这么做更多的是让别人明白不要指望马上得到回应。其实我查email比每3小时要频繁，但至少不用马上逼得去回每个email了，我可以憋着悠着点。因为如果真的很急，我的iPhone应该已经响过了。而且，批量处理真的效率要高很多。不骗你。
会议。开会太容易变成一群人互相在扯对方的蛋。浪费时间而且开完后发现没有结论且很蛋疼。但开会对于teamwork很多时候是必要的。如何主持会议是门学问，这里不细谈。不过，你不可能也不需要参加每个邀请你的会议。当你认为你参加某会议于己于人都无太多价值的时候，建议你考虑不去。如果想要有礼貌一点，那就写个email问问主持人你是否可以缺席。通常当你想过这个问题决定发这样的邮件时，答案通常都会是yes。有些时候我也会很可耻的让我的产品经理替我去开会。当然，我会鼓励他也争取不要去。Only make the meetings you really have to。同样，我要求我自己的团队在组织和参加会议的时候要慎重，也经常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例子。早些时候，我们会经常收到来自支持团队的比较随意的会面请求。这让攻城狮的一天被会议分割得支离破碎。写代码的都知道没有3-4个小时的连续时间是不容易高潮的。而且这种会议通常效率很低。于是，我们改变了做法，每周安排固定的答疑时间（office hour）和支持团队嗑想法然后follow up。当然，紧急的问题另当别论应当马上处理。
有一个被经常忽略的原则–有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免介入（比如韩寒和方舟子的–个人意见），哪些功能可以放弃，哪些关系不应该发展，哪些人应该开掉，等等。我经常问自己一个很简单的问题，我现在正在做的是否对我的目标很重要。如果你清楚自己正在做的和自己想要的，答案会明了。Go for it。
6、喜爱能有效地降低人们间的紧张。
工程师和支持团队之间有着纠结的合作竞争关系（注意，合作在前）。互联网技术公司中很多人（尤其是聪明人）总是期望工程师对所有问题给出一个让人会心一笑的解决方案。但现实是，不是每一个问题都可以或者应该在技术框架下解决。对于一些具体的问题，客户支持和运营部门会有一些非常深刻独到的见解。工程师未必行。毕竟很多见解需要不同的专业知识，依靠实地经验。没错，工程师可以在代码中自动log大量的原始数据，但从原始数据中提炼可靠的insight却并不总能如愿。就像大炼钢年代扔进去的是铁，出来的是铁疙瘩，而非期望的钢。和很多其他公司的客户或支持部门不同，我们的支持部门招募了质量相当好的员工（很多来自美国名校–在我直接接触的反欺诈支持组20来人中就有3名斯坦福校友）。因此，当两群都很聪明的人观点相左时，该听谁的呢？紧张关系再所难免。
不同的工程师团队也存在着合作竞争关系。反垃圾邮件、安全和反欺诈（我的团队）这几个团队之间存在密切的工作协作关系。这些团队也都尽可能地相互学习，分享经验和技术。但是，有时候各团队独立处理类似但不同的一些问题时，都试图向对方推销自己的解决方案和理念。
如何让合作竞争保持在一种健康有序的状态？我觉得关键是促进人与人之间的亲密感。把人搞近了，事情就容易了。我花大量时间用在建立和其他团队的关系上面。例如两周一次或者一月一次和其他团队老大们的1对1碰头会。越相关的团队，头碰得越频繁。我自己或者我的团队成员会有选择性的经常参加一些其他团队的会议。当为一个共同的大项目工作时，我曾安排不同的部门成员（工程师、支持、数据分析、金融财务）坐到一起进行项目冲刺。这是拉近相互之间距离的非常有效的一个做法，尤其对于减少扯皮的机会。因为互相之间经常会请或被请喝咖啡。我也会经常和一些人约定吃工作午餐，经常聊的是家常，增的是感情。有的时候一次长距离的散步也更能让人畅所欲言。而这样的紧密关系，在我们面对一个极具挑战性的项目的关键时刻，会帮助大家紧紧的抱团闯关。
7、托付并使之生效。
分配任务委托别人的重要性比较容易理解。因为你不是超人，不能端茶倒水什么都做吃喝拉撒什么都管。有些时候，你往往还不是最适合的人选。当团队一大事情一多，你一定要学会委托别人来负责合适的任务。对有些领导者而言，委托别人一个重要的目标可能不是很放心，觉都睡不好；但我非常习惯委托别人，有时候可能太习惯了。这是我一位前老板给我指出来的一个问题。有一次我给一位组员分配了一个既有技术难度又有协调挑战的难题。进程比较缓慢。但我给了他太多的时间空间来折腾，而事实上他在某些方面需要一些加强，有些方面需要我更多的主动的帮助。我老板指出来，如果我要让别人随便折腾的话，前提是我需要有足够的信心。我需要有事实来逐渐证明我的决定是正确的。需要谨慎委托。因为如果项目失败，对他而言，最终负责的人还是我，不是别人。所以我不能以别人不行来给失败的委托埋单。
如果你有一个重要的任务需要委托给别人，你要么
（1）已经对此人非常了解。知道他战斗力非凡可以搞定；或者相信他可以迅速学习提高打鸡血搞定；
要么
（2）需要在一开始手把手教他，时不时问他，直到你对他有足够的信心。
具体我是这么做的。项目开始时，我让被委托人给我一个整体计划以及几天内可以完成的任务。一开始经常会面跟进，然后确定后几天的任务。根据每次完成状况来估计他能不能”高快狠”地完成最终的目标。信心逐渐建成后可以减少关于该项目的细节讨论。此时的委托可以放得更开。但有一点要注意，如果跟的太紧的话，可能让人觉得你对他不放心，他也会做得畏首畏尾，这可能比盲目的委托还更差。所以在委托和谨慎之间，有一个微妙平衡。
8、反馈是一个持续过程，不是一个一年一两次的事件。
一年一度或两度的意见反馈在硅谷公司是非常常见的。它的目的不是设置起来给员工难堪，让他们互相责难的。它的目的是希望员工对自己对他人有更全面的认识，以助进步。意见反馈有自我反馈和同事反馈两部分。自我反馈是自己评定自己，完成了哪些目标，错失了哪些目标，哪些方面做好了，哪些方面还待进步。但由于是自己踢球兼裁判，难免有偏颇。同事反馈，就像一枚镜子，让你看到180度之外的自己。在Facebook，360度的正式意见反馈是一年两次，并且和薪酬挂钩。但近年来，意见反馈和薪酬评定逐渐分开。比如我做的一件事就是季度性的意见反馈，时间和正式评定错开。在那几天中，我请求所有相关组的同事在自愿的前提下给我写写关于我直属组员的意见反馈，短短几句都行。我会收集，综合，最后在1-1碰头会时反馈给我的组员。
如果需要等半年才来收集意见的话，很多相关故事早以忘得一干二净。故事越久远，记忆越模糊，意见越空洞，说了等于没说。而且，意见反馈和薪酬绑在一起，正常人（即使是牛人）都会很自然的把心眼更多的放到薪酬上，而不是意见本身。
除了季度性的轻型意见反馈，日常的意见反馈如果有的话应当立马传递。趁热打铁效果更好。
如何有效传递整理好的意见也很重要。有句话是说“it’s not what you say that matters， it’s how you say it”。我没那么极端，我觉得如何传递意见也同样重要。有两种方式我都试过，不确定哪种更有效。这里都谈一谈。一种是以问为主逐渐深入促其思考，比如“how did you think about the meeting you hosted yesterday”；另外一种是赤裸裸的直入主题，“hey， let’s talk about the meeting you held yesterday”，然后开始谈我自己的感觉。不管哪种方式，一定要给对方一个解释自己行为的机会；永远假设并告诉他我相信他的意愿是好的。为了避免陷入”你昨天做了xxx”“没有，我做的是yyy”“我觉你是做了xxx”的死循环式的争论，我首先争取和他们在”我们感知的即是事实”这一点上达成共识。基于这点前提，我们把讨论的重点放在如何做能改变别人的感受最后让事情能顺利完成，毕竟大多数重要的事都有很多人一同协作完成。当他们认识到自己想要改进某个方面的时候，如何改是一个相对容易很多的问题–聪明人一向能够找出改进的办法，我所做的就是配合他们做头脑风暴。最终谈话的目的是产生一个下次如何能做的更好的具体方案。
关于有效传递意见反馈，另有4点提一下。
（1）意见反馈不见得都是负面的。 它可以是别人的一个长处。 你很欣赏。 你希望他这方面坚持做， 做得更多。 比如一句”hey， I really love your weekly summary email with the key metrics at the top。 Please keep them coming”可能产生很好的激励效果。
（2）意见反馈必须摆事实和讲道理。 如果你只是告诉别人他很烂， 但不说什么时候浪过了以及为什么， 除了给他添点火气之外无他用。 所以我在相关人员包括自己写意见反馈的时候要求提供实例。 比如一句 “I think he could make meetings transparent and shorter by having an agenda， like the weekly data review meeting on last Friday”比”his meeting is too long”更有血有肉有效。
（3）意见反馈必须是可操作的。 让人无从下手的意见意义不大。 如果在提意见的同时提出一个方案以供参考就有意义的多。 但注意， 绝不能是命令的方式 (那是中青宝…)。 比如前面的例子“I think he could make meetings transparent and shorter by having an agenda sent ahead of time…”就很容易操作。
（4）（个人偏好）在最近的两个评价周期中，我给15个左右的同事（一半不直属我）写过意见反馈。我把我写的直接分享给他们。出于这种想法，在我下笔时就少了很多冲动。因为他们会读，所以我无法做到背后捅刀。因为他们要读，所以我需要写得有意义，容易理解，并且加上很多例子。并且，我欢迎他们和我直接讨论。如此一来，他们也明白我写这些反馈的一片苦心是为了他们进步。
9、你能干得比你想像的多。
这不是说说而已。我自己就有一个亲身的例子。我们曾经认为把一个高得离谱的欺诈率降到所允许的范围内会很难。的确很难。但想想看我们最终牛逼了一把，把它降到了比允许上限的一半还要低。感觉很爽。很长一段时间内整个团队士气高昂信心爆棚做事像开了外挂。
牛人们总是不断的超越自己。给他们一个离谱的目标，配以应有的工具，适当的帮助，足够的信心还有一定的时间，他们会让你大吃一惊，也会让自己大吃一惊。这一点，乔帮主是行家，屡试不爽。
但做到这一点有一个前提 - 不能害怕犯错。 如果犯错是被要严惩的失败是不允许的话， 牛人们只能在框框中被圈养， 没有办法实现突破。 有一句话我经常挂在嘴上“ask for forgiveness， not for permission”。 在Facebook， 大胆行事犯错是容易被原谅的。
但反过来，有一点要小心，就像第7点所说的–你不能随便把一个离谱的目标交给一个人，然后期待他来给你惊喜。盲目带来的可能是惊吓。你需要真正的牛人，至少是潜在牛人。而作为一个领导者，你的一个任务是帮助他们，鼓励他们，来引爆自己的潜力点。Facebook不缺此类待引爆的牛人。
10、不要过度设计和过早乐观。
有些工程师有一股出于本能的冲动想把自己的程序规模化，甚至在这些程序还没看到大规模使用的曙光之前。我在Facebook开始的时候，也是冲动型工程师一杯。但经历过几次失败的产品之后，我牢记了这个教训。不要过多设计或者过早优化。把核心功能设计的简单精炼。只有在看到产品有被大规模使用的趋势后，才来增加功能或增加规模量。有一个我做的产品使用的上限是200万月用户（当时Facebook整个月用户群是4000万左右），但我的实现已经做了很多额外的功来满足更多的用户。做的时候感觉很爽（感觉自己很牛，感觉再多人用产品也不会崩溃），之后感觉很惨。
但这一点不一定能适用于架构上的工作。比如Friendster这个网站的失败就是其基础架构的性能长期无法应对急速增长的用户以致网站很慢甚至崩溃。在用户增长高潮来临之前，你应该已经在架构上做了足够多的前戏。否则搞不好就要像Friendster收摊子散伙。但同时也要意识到，你所看到的用户访问模式，你的网站功能，在你只有10万用户的时候，可能和你有1亿用户的时候会很不一样。所有太多太早太频繁的架构上的大动作可能会适得其反。这一点上，你要小心判断。
在Facebook的4年半很好玩。我学到的感受到的远多于以上的十项。但希望这个分享能对朋友们有点帮助。同时祝所有的朋友在自己现在扮演的角色上都有好运。