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。


听君一席话