前 Facebook 工程总监黄易山的总结的 Facebook 五条工程管理经验

前 Facebook 工程总监黄易山的总结的 Facebook 五条工程管理经验：
招聘是第一位的；
让亲身实践者执行工作流程；
内部晋升；
工欲善其事，必先利其器；
技术型领导。

====================================土豆的华丽分割线===================================

Facebook前工程总监：招聘是第一位的

　文/黄易山

　　Facebook前工程总监黄易山（Yishan Wong）撰写了一系列文章，很好地总结了Facebook卓越研发文化中的宝贵经验。本刊将陆续连载这一系列，本文是第一篇。

　　从2006年底到2009年初，我有幸在Facebook的工程部门先后担任了不同的管理职务，包括几个不同团队的经理，以及工程总监，也见证了工程部由约30个人发展到200人左右。这段时间基本上跨越了从动态消息功能（News Feed）、Facebook平台（Facebook Platform）在第一届F8大会上的发布，到自助式广告系统（现在是我们现金流的主要来源）、网站国际化以及Facebook连接（Facebook Connect）的推出。2006年，我们还只是一家用户数不足1000万的基于大学的社交网络，而到了2009年初，我们在全球已经拥有超过2.5亿用户。这期间，公司也从一家小的创业公司（拥有不到100名员工）成长为一家中等规模的公司（拥有800多名员工）。

　　我到Facebook工作时，公司已经很明显将会迅速成长。我当时怀着这样的宏愿：在这个决定性的时刻，我要成为影响其关键决策的一份子，在遥远的未来，使Facebook和其工程部门能成为一个充满活力和具有持续性的机构。从我在其他经历了这种高速增长期的公司工作的经验中，我总结了一些有助于建立一个伟大工程环境的关键文化因素和组织因素。一方面，优秀人才愿意在这种环境中工作；另一方面，该环境允许最大限度地创新及快速地执行。如今，我又回到了一线工程师岗位。某日，我反思自己为何会享受在这样高效的工程环境下工作、为何会如此乐在其中。同事给我的答案是：“这就是建立优秀工程部门的‘Yishan’秘诀？”我从未想过以如此教条的方式来表达我的想法（实际上，这样做是危险的，因为它们会被神化），但无论如何，我决定努力试试看，看我能否将它们列成下面这样的清单。

招聘是第一位的
让亲身实践者执行工作流程
内部晋升
工欲善其事，必先利其器
技术型领导

　　注意，这其中并没有如何建立技术创业公司的各种显而易见的硅谷经验，例如“雇佣最优秀的人才”或者“建立一个可以确保开放沟通的环境”，因为这些早已众所周知了。清单中列出的是我认为不那么明显的事情，而这些事情很容易被快速增长的技术组织所忽视。相信那些能成功地将它们融入文化和惯例的公司，最终将变得更强大、持久、自新，而那些没这么做的公司，最终会变弱、陷入平庸。

　　在接下来，我会就每一点写一篇文章，分别阐述它们的含义及其之所以重要的原因。那些在过去几年里与我共事的人们，如果你看到这些文章，就能理解我当时为什么这么做了。希望大家能感受它们的用处和乐趣！

　　招聘是第一位的

　　招聘是第一位的，也就是说，“永远将招聘作为你的第一要务”：要将招聘作为你所在部门的第一要务、作为每个经理的第一要务、作为每个工程师的第一要务。

　　招聘需要多个部门的合作，并且包含很多阶段。概括起来就是：寻找候选人、筛选、面试、作决定、发出邀约、结束招聘。

　　在每个阶段里，要将与招聘有关的行动作为责任人的首要任务。举例来说，招聘人员需要及时与负责人进行沟通，并且在人力所及的范围内尽快安排面试以及后续的谈话。也就是说面试要优先于其他一切工作。要根据面试的结果尽快作出聘用或者不聘用的决定，并且尽快地发出工作邀约。如果能今天打给应聘者，招聘人员就不该等到明天；如果能安排这周面试，就不该等到下周。面试官不能因为其他事情推掉面试，也不能在几个小时甚至几天后才对面试做出反馈。招聘经理将反馈意见汇总到一起，以决定是否聘用，组织出一份邀约，并迅速结束对这名候选人的招聘。

　　各个部门是否赞成“招聘是第一位的”这种价值观，必然会对招聘过程的执行效率带来一些副产品和积极的因素。在聘用某些候选人（通常来说，是满足职位要求的候选人）时，有意识地“将招聘作为你的第一要务”正好提供了一种竞争优势；但它真正的好处在于促进了其他行为、价值观，结果有效地提高了员工的素质和工作场所的品质。

　　影响

　　引起了对高素质人才招聘标准以及如何在实践中施行此标准的重视。“雇佣最优秀的人才”是硅谷的一条至理名言，但很多公司却并没有能区分出“雇佣最优秀的人才”和“雇佣你所面试的候选人中最优秀的人才”之间的差别。成功地雇佣到“最优秀的人才”是你将招聘作为第一要务所带来的副产品，因为要将最优秀的人才吸引到你的公司来，需要将他们列入可选的名单，再对他们进行有效地评估，然后从竞争激烈的邀约中脱颖而出—要达成这样的整体效果，需要每位相关人员全心投入，并且做好每一件基本的工作。

　　如何才能设定高标准？如何测试一个候选人是否符合这些标准？这两件事都是说起来容易做起来难，因此只有让招聘在大家的意识中占据首要位置，普通员工和经理们才能自然而然地将精力放在诸如此类的事情上：哪些是有效的面试技巧，面试中问哪类问题最好，如何有效区分面试中的好征兆和坏征兆，以及训练面试人员中的骨干后续如何有效、重复地实践以上技巧。要自发地做到这些，需要耗费巨大的集体精力，而且除非每个人都沉浸在一种“招聘压倒一切”的文化氛围中，否则这一切都不可能发生。招聘是件混乱、无法精密计划的麻烦事儿（这也正是技术人员所痛恨的），所以除非招聘人员确信它很重要，否则你没法调动他们的积极性。

　　这也意味着每个人都是面试官（或者说公司里的每个人至少有一部分时间是面试官）。既然招聘是每个人的当务之急，那么没有哪个人可以避免参与到面试（以及其他与招聘有关的活动）中来。应该避免这样的情况—某个工程师说：“我只想写代码，你们这些人去做面试和招聘工作吧。”

　　这会造成一系列影响。首先，它意味着更多的人会和最终加入的候选人接触，这有助于团队联系的快速建立——新人进入工作场所时，而其中有一些人是他已经见过面的，并且他知道这些人赞成并欢迎他的到来。其次，它把维持工作场所品质的权力交到了每个人的手中。人员的高素质不只是管理人员在象牙塔里决定的事情，它与每个人的行为都息息相关。在高速增长的公司中，最常问到的一个问题是：“我们怎样确保雇佣到的人是最顶尖的？”答案是：如果每个人都参与到面试中来，都以此为己任。公司里的每个人都应该承担以下的责任：不断使自己更善于判断某个人是否有资格加入公司；对候选人进行严格的测试；在不确定该候选人合格时说“不”；而最重要的也许是，坚定立场并且坚持否决招聘（“这绝对不行，除非我死了”），这是因为你在某个候选人身上看到了无法忽略的危险信号，因为你也是标准和公司文化的捍卫者。

　　同事的素质是工作场所幸福度的最大决定因素，而改善大家工作体验的最主要的方式就是，每个人都充分地参与其中。

　　它也改善了你寻找候选人的渠道。招聘人员无法搜寻到和筛选出最佳的技术人才，因为他们本身不是技术人员。以招聘作为优先任务会激励你现有的最优秀的员工，他们会寻找和推荐接触到的最优秀的人选，这就构成了你成功的候选人渠道的主体。同样，这并不容易做到（一个天然的障碍是，人们不愿去一遍又一遍地烦扰自己有才华的朋友），除非大家认为这件事是当务之急。

　　你会得到（客观上的）最优秀的人选。这是引人注目的、理想的最终结果，但是只有在给予足够的重视和行动后，才后出现这种结果。招聘是一个零和博弈游戏。候选人不加入你的公司，就会加入你的竞争对手，你的损失将是他们的收益。如果没有将招聘作为首要任务，就不太可能会在招聘中领先。这意味着别人会领先，真正的最佳候选人将会加入他们，而你雇佣到的是“能面试到的最优秀的人选”。

　　长期影响

　　最明显的一个长期影响是，对招聘的重视造成的影响反过来促进了这种重视。一旦这种重视能带来成功的招聘，就会很容易延续下去。特别是优秀的人才加入公司，并且积极地支持这种文化氛围，以确保更多的优秀人才加入。这些影响要在几年后才会显现，因为即使拥有比竞争对手略微优秀的人才，随着时间的推移，也会形成倍增的效果。首先，你努力聘请到最优秀的人才，然后你得到最优秀的人才，然后你得到最好的结果。

　　在更广泛的组织水平上，这也会产生高素质的招聘经理和经理候选人（那些日后可以从内部提拔为经理的人）。优秀的管理者会认识到人的重要性，并且寻找愿意将这种价值观应用到实践中的组织。拥有高素质的管理人员，对公司运营的其他几个重要方面（包括有效的绩效管理，设计和部署有效的激励机制，推动有强大执行力的企业文化）是至关重要的。

　　成功地雇佣各个级别的优秀人才，意味着一段时间以后，你将拥有强大的内部晋升渠道。这使你可以更容易从内部提拔人员和减少寻找外部候选人（这总是存在风险的）的必要。反过来，这意味着新的主动权、组织的成长、战略上的变化、对退休领导人的补充——任何可能需要新领导者的情况——都可以搞定，而且能够有更优的人选，风险也更小。

　　（本文来自《程序员》杂志11年03期，更多精彩内容敬请关注03期杂志）

==================================土豆的华丽分割线=================================

Facebook前工程总监黄易山 让亲身实践者执行工作流程；

文 / 黄易山

黄易山

黄易山

在这里，我使用“工作流程”这个词来描述“个人或团体为了完成一项活动而遵循的步骤”意义上的流程，以及组织的一般制度。随着一家公司的成长，有必要增加或整理工作流程。

最重要的利弊权衡通常是工作流程所带来的阻力，以及效率或效益上的收益孰轻孰重。

一方面，很难评估这种权衡中的利弊，因为其中牵涉到很多因素，所以有一条可能会有帮助的原则：只允许那些有特殊需要的工作流程被执行，而且要由那些直接使用它的人来执行。通常，经理和管理人员会提议工作流程，因为它会帮助他们更好地指挥、控制、协调或沟通。但新工作流程的执行不应该为这些目标服务，因为它的收益是不实际的，而且往往被高估：管理人员可以看到它带来的好处，但由于至少在一个（或多个）层面上不需要他们的直接操作，所以他们没有认识到它的真实成本。

另一方面，那些亲自动手的人（如工程师）可以很容易地辨别，何时需要适当补充组织要素或工作流程，因为他们可以更直接地认识到收益将大于成本。只有在这种时候，才应该在组织中增加一个新制度或工作流程。

经理们必须抑制住自己天生的恐惧，不要害怕由于缺乏对细节的能见度而造成的混乱或失控。他们应该重视依靠建立准确、翔实的背景情况和目标来进行领导，促进技术工人（不知为何，他们通常不是那种容易陷入无政府状态的人）之间互相合作而形成的自然组织。
影响


个人制定并执行的工作流程，会针对真实工作的情况进行更多优化调整。管理者设计的工作流程，最多能接近实际工作流程，它需要管理、优化或整理。这是许多愚蠢、低效的工作流程的来源。

在人们亲自制定工作流程时，会感到更大的自主权。在今后，随着情况不可避免地变化，也就更有权视情况对其调整，而不是任其僵化。外部强加的（自上而下的）工作流程更加难以打破，而且往往会被神化，从而产生非常大的组织惯性。

对协调和沟通的影响

对于协调和沟通，会有什么影响？这些不是管理者的职责所在吗？是的，这是他们的重要职能之一。然而，为此而创建的工作流程应该由经理来执行，而不能强加在普通员工身上。例如，团队状况和项目更新的广播是一种有用的功能，可以通知该部门或公司的其他人哪些事情正在发生。这是一个完全可以由管理人员完成的工作流程，并不需要团队中其他人的直接参与：经理可以撰写这些更新并分发给团队成员，但他不应该反过来要求团队成员也做同样的事情，因为经理与他们一同工作，可以（也应该）知晓团队运行的状况。

这里的关键是，我们有一个有益于管理人员的工作流程，而这其中的成本也由他们承担，从而允许他们为自己的共同利益对工作流程进行优化。这不需要（也不应该）涉及到其他任何人。

描述性工作流程的微妙危险

指令性的工作流程意思是“这是为了完成X，你必须采取的步骤”，描述性的工作流程则是 “今天我们完成X后，让我们记录下采取过的步骤”。首先，描述性的工作流程是一个普通的、看似无害的建议，但不可避免地会导致同样的不必要的工作流程要求和僵化的组织制度，因此我们应该同样积极地避免使用它。

首先，写下“我们通过这些步骤，完成了X”（其中的X可能是“推出一款产品”或“将一个想法从概念变为现实”或“申请一张新桌子”）的无害建议被采纳，而且这个工作流程被归档成一份文件，然后（也许）会被张贴在公司内部网络上。

然后有一天，一名新人问道：“我们该怎么完成X？”在回答时，我们不再像老前辈那样非正式地解释完成X要如何如何，而是让他们去参考那份文件。毕竟，这比口头解释更简单快捷。在快速成长的组织中，新人加入的速度很快；很快地，这名新人变成了老前辈。另一名新人碰巧问他们同样的问题，这次轮到他们让别人去参考那份文件了。这个过程重复循环几次，该文件就被视为完成X的权威指南了。

在公司现有的大多数人（在快速成长的公司中，新人总是比老前辈多）的概念中，原创的具有适应性的工作流程（适应性强、有机和运作良好，而且它的非正式使人们觉得它灵活）被文件所取代，文件现在被看成做某事的非常精确的规范。

巧妙、可控制的灵活性减少，而且描述性工作流程成为了规范，但这无法归咎任何人。有时会更糟，因为有意的指令性工作流程存在的背后通常有一个权威的、能够亲自站出来呼吁的特定的人支持。僵化的原创性工作流程存在的背后有一篇单独的文件支持，给人们一种无法形容的类似法律的权威感，也就是说，超越任何一个个人的权威，在必要时就更加难以推翻和创新。

长期影响

在不同时期，我都曾参与过对潜在收购目标的慎重调查。最令人惊讶的发现之一是，在许多情况下，一个相对较小的公司却有更多的正规工作流程，这主要是由它们自己的员工所导致的，也是他们发展相对缓慢的原因：很少想法能得到执行，并最终导致了相对弱势的市场地位（有时，这是我们认真考虑某次收购的原因）。

在Facebook，公司文化与工作流程是有抵触的，引入新工作流程的通常模式是“只有在事情快要不可收拾的时候，才会考虑引入新的工作流程”。尽可能地做到这一点，而且可能要更变本加厉，因为这样你所得到的回报将是整个公司的高效率。如果你的公司比其他同等规模的公司拥有更少的工作流程，你的创新和执行速度会更快，将想法从一个概念到最后推向市场也会更加快速。在内心深处，经理可能要和更多让他们不安心的混乱作斗争，但是让人不安心的混乱和真正对公司造成威胁的混乱有着很大的区别。越接近后一时刻，就越能够对比出技术行业的最大的优势之一：执行速度。

工作流程通常建立在有规律的和大致固定的执行速度的基础上。因此，形成这种执行速度是保持长期高效的关键。如果你的公司有特定数量的工作流程，而且比其他同等规模的公司要少，那么你的执行速度会更快，而当你的公司变得异常庞大时，其中的官僚主义也比较少，这同样会产生倍增效果：当公司规模较小时，执行速度快两倍，意味着同一件事，你需要两个星期完成，而你的竞争对手需要四个星期；而一旦公司规模扩大，你可以在两年内完成的一件事，你的竞争对手需要另外两年才能迎头赶上。这多出来的两年对他们来说，可能意味着末日。

（本文来自《程序员》杂志11年04期，更多精彩内容敬请关注04期杂志）

======================================土豆的华丽分割线==================================

Facebook前工程总监黄易山 内部晋升

文/黄易山黄易山

Facebook前工程总监黄易山（Yishan Wong）撰写了一系列文章，很好地总结了Facebook卓越研发文化中的宝贵经验。本刊将继续连载这一系列，本文是第三篇。

建设一家健康长久的公司，“从公司内部提拔管理者”是一条广为人知的建议。这条建议也同样适用于规模较小、发展迅速的创业公司。

内部晋升的困难

对于超速发展的创业公司来说，秉持内部晋升的方针既非常有必要，同时又非常困难，具体有以下几个原因。

由于公司的超速发展和组织的壮大，因此对于新鲜血液的需求也就非常大。普通员工确实可以从外部招聘，但寻找领导时，想要完全屏蔽外部渠道就变得更加困难。公司主管必须对此保持非常清醒的认识，并且经过深思熟虑后，才能下定决心不从外部招聘领导者。

外部渠道常常被看作是不可思议的完美人选的来源（外面有这么多合适的人选），但实际并非如此。一个成功的管理者需要理解公司文化和公司价值的精髓部分，这通常包括：是什么造就了这家新公司的不可复制的成功以及下一步应该采取哪些步骤。一份令人印象深刻的简历，或是大公司里的同事对他业绩的评价，都不足以证明他能胜任这份工作。

公司内部不一定有足够多的能完全胜任的内部人选。创业公司的主体人员主要由优秀的普通员工构成，而领导的候选人则一般是他们之中最优秀的。所以从前面两个原因可以看出，若提拔这些人会直接导致他们的业务能力下降，并且也不能保证他们在做管理工作时会像做技术工作时一样优秀。

从外部招聘的弊端

尽管内部晋升存在上述困难，但从外部招聘经理或高管并非良策。

招聘经理或高管本身就是种冒险。

任何招聘从根本上来说都是一种。即使进行了细致的面试和筛选工作，你仍然不清楚最终被雇用的人是庸才还是天才。工程师的招聘成功率不会超过80%，经理或高管的招聘成功率则不会超过50%。

这意味着，一名从外部招聘来的经理，有50%的可能会是一个不但不擅长工作，而且会给公司带来致命损害的人。一名糟糕的工程师意味着一场灾难，但通常不是致命的，而糟糕的经理或高管则意味着致命的灾难，公司有可能无法从他所带来的灾难中恢复过来。

你要明白一点，经验丰富的管理者会经常参与招聘，因此他们非常擅长让自己在面试中显得很优秀。

外部招聘的经理很可能会使你放慢公司的发展速度。

这是因为经验丰富的管理者通常来自于大公司，小公司难以培养出很多管理者（因为没有那么多人需要管理，如果有的话，那它就不能被称为小公司了），所以大部分的管理者都来自于大公司。外来的管理者会理解、保持并巩固企业内部文化的概率并不大，他们很可能带来之前任职过的大公司的文化。这会成为减缓公司内部执行力的最强的一股力量，因为他们往往会在时机明显不成熟的时候就引入一些工作流程和方法（而理由通常是，为公司规模的扩大做好准备）。

当公司或工程部门的规模在某一水平之下时（具体地说，是拥有150~250名员工时，这个数目与Dunbar’s number（邓巴数）相符，即一个人能够与之维持紧密人际关系的人数上限），企业文化刚刚开始产生，而且起主导作用的仍是每个人的个性和团体的惯例。领导者在企业文化的塑造中所起的作用非常强大，所以一名新领导很容易让整个创业公司将注意力从公司真正的成长方向和市场前景上转移开，从而导致公司失去竞争优势。

不止一家创业公司由于一时疏忽搬起石头砸了自己的脚，它们往往在第一轮或第二轮融资后，就决定要招聘一位职业经理或者副总裁来“帮助团队成长”。但实际情况是，企业规模扩大了，工作流程得以落实，而执行力则大大下降，市场目标变得不明确，若不尽快解聘这位经理或高管，公司将无法继续发展下去。

Facebook的内部晋升经验

因此，成功地坚持内部晋升的方针不仅非常重要，并且也异常困难。这里有一些方法供参考。

寻找那些愿意以普通员工身份加入公司的管理人选。如果公司还是低于一定规模的话，才能出众的技术经理非常适合在这时以普通员工的身份加入，并会快速成长为一名管理者，而且你应该鼓励他们这么做。

这也是筛选出那些曾任职于大公司，但也有能力管理好小公司（或者可以很快领会公司文化，胜任这一工作）的不可多得的管理人才的好办法。同时，这也是对拥有独特技术才能的技术型领导的一种有效考验，因为他们有一次又一次地证明自己能力的信心。拥有在类似创业公司工作的直接经验的人才，通常分为以下两类。一类是那些曾经自己创立创业公司，但是因为种种原因（比如说收购）而成为大公司的职业经理的人。另一类是那些曾经在某创业公司规模还比较小（和你现在公司差不多规模）的时期工作过的经理。

如果一名经理没有过在像你这样小规模的公司任职的经历，不要雇用他。因为他们肯定无法融入并运营你的业务，而且还会戴着“凭我在大公司的经验，这件事应该这样做”的有色眼镜看问题。那样的话，你的工程部门、你的公司，都必死无疑。

让少数通过内部渠道晋升的经验丰富的经理对较缺乏经验的经理进行指导，以训练他们的管理能力；如果这个办法行不通，也可以从外面请管理培训师进行指导。一般来说，大部分管理者人选都会展现出自己的管理潜质，但还无法完全胜任这个角色。直到他们完全胜任了自己的角色，对于个人、同事以及整个团队来说才是真正渡过了困难时期。

新任经理应该得到特别的关注，最重要的是让他们明白如何才能适应自己模棱两可的身份，担负起员工管理的重责，并且建立起信心。长期缺乏关注，再加上创业公司超速发展带来的压力，通常会让他们马失前蹄（被降职或自行降职），还会造成团队士气的低落。

经过慎重考虑、权衡利弊后，最终得到的结论是：经过频繁且适当的指导，一名对公司文化有着深刻理解、具备领导潜质且曾对公司发展目标有过贡献的内部人选很有可能顺利成为公司的一名管理者。这样的内部人选远强过一个实际能力、文化倾向和动机都存疑的外部人选。

长期影响

一旦组织的规模成功地超过150~200名员工（邓巴数）这一阶段，公司文化已完整保留并渗透到运营惯例中，也开始自我加强，这时可以逐步地引入外来管理者，让他们直接就任管理职位而无需内部晋升（无论如何，继续通过内部晋升来任命大部分的领导职位仍是个明智的选择），如此可以使管理阶层的技巧变得成熟。这时，公司文化已经强过任何新任经理的影响，而且会变成一股巨大的力量，排斥那些不能融入这种文化的管理人选，从而得到自我加强。

对于早期加入网景公司（Netscape）和后期才加入的人，Jamie Zawinski有几句著名的描述：早期加入的人是“为了创造一家伟大的公司”，后期加入的人们则是“因为这是一家伟大的公司”，而且在他看来，这一点与这家公司之后的黯淡表现有着重要联系。

后期加入公司的人的动机——特别是在公司取得巨大成功（更“糟”的是，在公司取得巨大的财务上的成功）之后加入的人的动机是非常值得怀疑的——他们有可能是为了钱或安全或稳定，或者三者兼而有之，也就是“因为这是一家伟大的公司”，而不太可能接受公司早期的核心价值。这不是我们希望看到的，而且它会成为损害公司更长远的成功和活力的罪魁祸首。具有这种动机的管理人员被雇佣后，会对公司未来的决策带来很不好的影响。

避免这种情况的方法就是在早期培养足够的领导后备人选，并且最终成功地将他们提拔到领导岗位上来，从而建立一个晋升渠道，晋升渠道中的人选主要是那些早期加入而且“为了创造一家伟大的公司”的人。新加入的员工也可以作为这个渠道的资源，形成一个不断前进的系统。在将他们提升到有影响力的领导岗位上之前，应向他们灌输适当的企业价值观念。

作者简介：黄易山，1997年毕业于卡内基-梅隆大学。2001年加入PayPal，曾任高级工程总监。2005-2010年在Facebook领导研发，在公司研发环境的建设上发挥了重要作用。

（本文选自《程序员》杂志11年05期，更多精彩内容敬请关注05期杂志）

=====================================土豆的华丽分割线==================================

Engineering Management - Tools Are Top Priority

第四和第五点还没有中文翻译，那么我们就贴英文吧


This is the fourth part of a series of notes regarding my thoughts during my time in engineering management at Facebook. Read the intro here.
Tools are top priority
The core premise of any technology-driven company is that it is providing a tool that makes human life better, faster, more effective. Driving the effectiveness of that company and especially its own technology operations is the effectiveness of its tools.

Over and over, the successive waves of new startups with structurally more advanced operations (think Google with the massive compute power of its datacenters, or startups which can build an entire website with just a small team) are enabled due to an advance in tools. Computerized tools, unlike physical tools, can stack their leverage arbitrarily upon each other, compounding their leverage to enormously high levels.

Hence, your operating efficiency, and thus the number of people you need to hire, and therefore your costs, are directly impacted by the ingenuity of your internal tools. This means that your tools teams should not be a back-office, after-thought function staffed with second-string players. Your most talented engineers should be working on your tools, and your culture must reflect this priority. Writing great tools and continuing to improve and replace them is more important than the next shiny feature.

Example 1: At Facebook, there was a time (2005 thru mid-2006) when we hired customer service people at a constant ratio with user growth. When we had 10M users, we had less than 20 people in customer service. As we climbed towards our first 100M users, it was clear we could not just staff this up by 10x, so we charged our internal tools team with working closely with our customer service analysts to build ever more innovative tools and user interfaces to improve the efficiency of our customer service department by orders of magnitude. Today, we have only ~3x more customer service people (i.e. around 60-70), serving well over 325M users. There is no external company, off-the-shelf product, or management consulting strategy that could have yielded an order-of-magnitude gain in personnel effectiveness; it was the work of a small internal tools team that analyzed the work being done and created custom tools to streamline it by automating the parts that a computer could do quickly while optimizing the experience so that the human analyst could concentrate on what humans were best at.

Example 2: Well past the time when we had hundreds of database machines (and tens of thousands of database instances spread across them), instead of hiring DBAs, we had a single database engineer who administered all of those machines by writing ever more effective tools. Today Facebook continues to manage thousands of databases with only a handful of database-oriented personnel. The original "second DBA" was even only hired because eventually our first database engineer decided she wanted someone else to cover the night shift.

The quality of your tools and your ability to continue to evolve them will allow you to suppress the need to hire for operational roles, allowing each front-line individual to do more, which simultaneously improving overall coordination (fewer people means coordination is easier) and keeps costs down. Today, the results of Facebook's engineering leverage ratio means that there is one engineer for every 1.2 million users and despite our blistering user growth, the ratio is growing. While some of Facebook's best engineers work directly on front-line features, a large percentage of them work on internal abstractions and tool frameworks that end users never see, but which vastly magnify the effectiveness and power of their fellow engineers.

If your culture reflects this priority, you'll have no problem getting your best engineers to work on improving tools. The best engineers tend to go where they have the greatest impact.

Today, a mere decade after the first dot-com boom, the web division of the New York Times uses more advanced technology and gets more done with fewer people than many of the original titans of Web 1.0. If your technology company today is a leader in anything, it is because it was likely started with the latest in tool technology. You will not retain this position without a culture that values an ongoing first-class investment in your internal tools, because if you don't, not only will your competitors who do pass you by, so will the entire market.

http://www.algeri-wong.com/yishan/engineering-management-tools-are-top-priority.html

=====================================土豆的华丽分割线==============================

Engineering Management - Technical Leaders

This is the fifth and final part of a series of notes regarding my thoughts during my time in engineering management at Facebook. Read the intro here.
Technical Leaders
All external management hires must be able to write code and show a high level of technical proficiency, up to and including the head of the technical department. If the company is a technology company, this should also include the CEO.

There is an odd misconception that this is not a necessary requirement for an executive or manager, as though programming were just a fancy form of typing. No other specialized industry seems to feel this way: banking executives are expected to be able to read a balance sheet; an automotive executive would never be hired if they didn't know what a catalytic converter did.

Alternatively, it's sometimes said that technical proficiency is impossible to test for, because a great management candidate will have likely spent the last few years managing, and not directly in touch with the technology. And besides, a great people manager can manage anything. This is false.

Certainly the candidate should not be expected to build a full-scale system at the limit of current scalability technologies, or tune a chipset down at the metal, or recite obscure syntax for a particular language or framework. But it is entirely reasonable and desirable to test if a management candidate has a strong individual technical background. I refer to basic tests for skills which, if the candidate had ever been a competent technical contributor they will inevitably retain, such as coding tests involving some simple iterative or recursive algorithm, and conceptual tests involving elementary computer science concepts like pointers, hashing, and operating system fundamentals.

For example, one particularly low bar includes the fizzbuzz question. Many readers here may assume that this is a test that any programmer could pass, but this is not true. There are numerous, numerous programmers who cannot do this (not that being able to do this means you're a good programmer, but not being able to do it definitely means you're NOT) and early in their careers, they found they weren't good programmers, and because they happened to be in an organization without strong technical rigor, they were promoted because they happened to be good with people (or good at using people). Many of these people fill the ranks of technical management and executive candidates today.

Furthermore, they are usually very skilled at talking a good game and sounding like they know what they're doing (or they wouldn't have gotten there). The only way to determine if a candidate has real technical competence is to either (1) subject them directly to a simple coding test of the nature I described or (2) find some open-source code they've written which you can directly evaluate. [Example]

Candidates who cannot pass these tests or who don't have a verifiable record of public technical work should not be hired.

The reasons should be obvious, which is that management needs to be able to tell what's going on in order to make informed decisions. A skilled non-technical manager can get a pretty good idea, but all other things being equal, they will be outperformed by a similarly-skilled manager who has a technical background. Further, they will certainly not be able to provide technical leadership, and if you want your company to be a technical leader, your leaders first need to be technical.

A "technical" organization whose leadership is non-technical fails in one or both of the following ways:

1) Leaders are unable to tell when the technical staff is not performing up to snuff, because they cannot reliably differentiate between excuses for poor technical performance and true obstacles that arise when contending with difficult technical challenges. Performance management then becomes impossible, leading to mediocre work and eventually, outright and repeated project failures.

2) Business needs cause leaders to override the suggestions or opinions of the technical staff. Today's harsh business environment requires that business leaders push their organizations continually beyond their old boundaries, and sometimes this means that a leader has to tell their staff to "damn the torpedoes" and stretch further than they are comfortable. Unfortunately, a non-technical leader has no personal ability to gauge the actual risk profile of overriding technical suggestions (i.e. shrewdly exceeding old limits in certain special situations) and is then prone to eventually overriding technical advice which should not be overridden.

At companies other than Facebook, I have witnessed more than one large system failure that stemmed from a lack of core technical literacy in the executive staff. At Facebook, individual technical competence happens to be required of all engineering management staff and extends all the way up to the head of the department and includes the CEO (who continues to participate in Hackathons). This allows the company to repeatedly take daring technical risks in order to achieve significantly innovative product goals and execute at a consistently rapid pace: the more you understand the rules of the game, the better you can play it.

http://www.algeri-wong.com/yishan/engineering-management-technical-leaders.html