Engineering Management

This means "make hiring your number one priority, always."

This means that it needs to be your organization's first priority, it needs to be each manager's first priority, and it needs to be each engineer's first priority.

Hiring is a function requiring cooperation from multiple departments and consists of multiple phases; roughly speaking: sourcing, screening, interviewing, deciding, offer-making, and closing. At each stage this means making the relevant actions the top priority of the responsible actor, e.g. it means that recruiters contact a lead immediately, and schedule an interview or follow-up conversations to occur at the first humanly-possible time slot. It means that doing an interview takes priority over other work. It means that hire/no-hire decisions are made as soon as possible upon conclusion of the interviews, and offers made with subsequent speed. Recruiters don't wait until the next day to call a candidate or schedule them for next week. Interviewers don't skip an interview because they have other things to do. Interviewers don't wait a few hours or days to give their feedback on an interview. Hiring managers coalesce the feedback, facillitate a decision, put together an offer, and begin closing the candidate immediately.

The resultant execution speed of the hiring process is a side-effect and a good indicator of whether or not all parties involved are upholding this value. It happens to provide a competitive advantage in hiring certain candidates (typically satisficers), but the real benefit of consciously making hiring the top priority over everything is that it drives other behaviors, values, and results which improve the quality of people and the workplace.

Effects:

1)It creates a focus on high-quality hiring standards, and how to achieve them in practice. "Hire the best" is a well-known Silicon Valley maxim, but many companies fail to diffrentiate between "hiring the best" and "hiring the best candidate you interviewed." Successfully hiring the best is a side-effect of making hiring your top priority, because attracting the best candidates to your company, making yourself a viable employment option to them, evaluating them effectively, and then standing out among competing offers is a holistic effect that can only be achieved if everyone involved cares about it enough to do the nitty-gritty things that make all of that happen.

How do you have high standards? Furthermore, how do you test if a candidate measures up to them? Since both are easier said than done, it is only once a culture of giving hiring top priority in peoples' attentions will individuals and managers naturally begin directing their energy into doing things like deciding what constitutes effective interviewing techniques, what kinds of questions are best to ask, how to effectively diffrentiate between good and bad signals in an interview, etc, and subsequently how to train the entire cadre of interviewers to be able to effectively and repeatably practice this. The willingness to do this takes an enormous amount of collective energy, and it simply can't occur until everyone is suffused in a culture that values the practice of hiring above all else. Hiring is hard; it is messy and imprecise (which technical people hate), and so you can't make anyone do all this unless they first believe it's important.

2)It also means that everyone interviews (or everyone who has been at the company at least some minimum amount of time). Since hiring is everyone's top priority, there should be no one for whom interviewing (and participating in other hiring-related activities) is an optional activity. It should eliminate the occurence of the engineer who says "I just want to code; you guys do the interviewing and hiring."

This has a number of effects. First, it means that more people are bought in to the candidates who eventually join, and team bonding gets a jumpstart - new people join a workplace where they have already met several people, and know that these people approve of and welcome them. Second, it puts the power of maintaining the quality of one's workplace into everyone's hands. Personnel excellence is not just something management handles off in some ivory tower, it lives and dies through the practice of individuals. A question is often asked in hyper-growth companies, "How are we ensuring that all these people we're hiring are top-notch people?" The answer, if everyone interviews, is "It's YOUR job." To each and every individual, it's your job to continually make yourself better at determining if someone is qualified to join, it's your job to test them rigorously, it's your job to say no-hire if you're just not sure about them and perhaps most importantly, it's your job to sometimes put your foot down and insist on vetoing a hire ("over my dead body") because there is just a red flag with a particular candidate that you can't let pass, because YOU TOO are a guardian of our standards and our culture.

The quality of coworkers is the single greatest determinant of workplace happiness, and fully engaged participation by everyone is the primary way by which everyone exercises direct power over making their job experience better.

3)It also improves your sourcing pipeline. Recruiters are not able to find and screen the best technical talent. They are not technical people. Hiring as a priority is what will motivate your best existing people to seek out and refer their best contacts, and this is what will constitute the majority of your successful candidate pipeline. Again, this is easy not to do (there is a natural reluctance to bug one's talented friend over and over again) unless everyone believes in the priority.

4)You will begin to get the (objectively) best candidates. This is the obvious and desired final outcome, but only begins to happen once the priority and practice are in place. Hiring is a zero-sum game. Candidates that don't join your company will join a competitor's, and your loss will be their gain. If hiring isn't your number one priority, it's unlikely you'll be number one at hiring, which means someone else will, and the true best candidates will go to them, while you'll be left to hire the "best candidate you were able to interview."

Longer-term effects:

1)The most obvious one is that the effects of attention to hiring compounds itself. Once it's shown that it breeds success in hiring, it is easier to continue, especially as good people join the company and enthusiastically support that element of the culture in order to ensure that more good people join. These effects are felt for years to come, since having even slightly better people than the competition is a growing force multiplier as time progresses. First you work hard to hire the best, then you get the best people, then you produce the best results.

2)On a broader organizational level, this also results in hiring high-quality managers and management candidates (individuals who can be later promoted internally to managers). Great managers recognize that people count, and look to find an organization where this value is reflected in practice. The presence of high-quality managers is critical to several other important aspects of operation, including effective performance management, designing and deploying effective incentive structures, and driving a culture of strong execution.

3)Succesfully hiring the best people at all levels means that down the road, your internal promotion pipeline is strong. This allows you to promote more easily from within and relieves you of the need to source external candidates (always risky). This in turn means that new initiatives, organizational growth, changes in strategy, and backfilling retiring leaders - all things which potentially need new leaders to step up - can be undertaken with greater confidence and lower risk.

---

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

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

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

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

影响

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

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

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

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

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

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

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

长期影响

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

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

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

Here, I use process to describe both process in the sense of "the steps an individual or group follows in order to perform a function" as well as general systems of organization.

As a company scales, it becomes necessary to add or codify process. The key tradeoff under consideration is always whether the drag imposed by the process is worth the gains in efficiency or effectiveness.

It is difficult to assess this tradeoff since so many factors are involved, so here is one principle which may be orthogonally helpful: only allow processes to be implemented which are specifically desired and put into place by those who will be directly involved in using it. Often, managers and executives suggest process because it will help them better command, control, coordinate, or communicate. New process should never be implemented in the service of these goals, because its benefit is illusory and often highly overestimated: managers can perceive its benefits to them, but because they are at least one (or more) levels removed from the direct operation, they do not perceive its true costs.

On the other hand, individuals doing hands-on work (e.g. engineers) can easily recognize when it is appropriate to add elements of organization or process, as they have a more direct ability to see how the benefits would outweigh the costs. That is the only time when a new system of organization or process should be added.

Managers will need to suppress their natural fear that things are too chaotic or out of control due to the lack of visibility into details. They should focus on leading by setting accurate and informative context and goals, facillitating the natural organization that results from collaboration between technology workers (who are often not the type prone to falling into anarchy anyhow).

Effects:

A process created and implemented by the individual contributors themselves is much more tuned to optimize the real work being done. A process designed by managers at best approximates the actual flow of work that it needs to govern, optimize, or codify. This is the source of many clueless and inefficient processes.

People feel greater ownership over process they create themselves, and are thus more empowered to adjust it in the future as circumstances inevitably evolve rather than allow it to calcify. Process imposed externally ("from above") is more difficult to break down and tends to be unnecessarily enshrined, thus producing extra organizational inertia.

On coordination and communication:

What about coordination and communication? Don't managers need to do that? The answer is yes; it's one of their vital functions. However, process created to serve this should be process practiced amongst managers, and not imposed on individual contributors.

For example, the broadcasting of team status and project updates is a useful function to help inform others in the department or company of what's going on. This is a process that can be done entirely by managers, and does not need the direct participation of individuals on their teams, i.e. managers can compose these updates and circulate them but should not be recursively requiring them of their team members, since the manager can (and should) be aware of team operations as a result of working with them.

The key is that here, we have a process that benefits managers wherein the cost is also borne by them, thus allowing them to optimize the process for their own mutual benefits. It doesn't (and shouldn't) need to involve anyone else.

Regarding subtle dangers of descriptive process:

Prescriptive process says "Here are the steps you must take in order to do X." Descriptive process says, "Let's write down the steps we're taking today when we do X." Descriptive process is, at first, a common and harmless-seeming suggestion but leads inexorably to the same unnecessary process requirements and calcified systems of organization, and therefore should be avoided with the same vigor:

First, the harmless suggestion to write down "the steps we go through to do X" is taken up (where X might be "launch a product" or "take an idea from conception to delivery" or "request a new desk"), and the process is described in a document and posted onto (perhaps) an intranet page.

Then one day, a new person asks, "How do we do X?" In reply, instead of an old-timer explaining to them informally how they individually might go about doing X, they are referred to the document. After all, it's easier than explaining verbally. In a fast-growing organization, new people join rapidly; soon, this new person becomes an old-timer. Another new person happens to ask them, and they in turn are referred to the document. This cycle repeats merely a couple of times, and the document itself becomes viewed as the authority on how something is done.

The original ad-hoc process (which was adaptable, organic, and worked well because its informality allowed people to perceive it as flexible) has been replaced in the minds of most of the current people (newer people always outnumber old-timers in a hyper-growth company) by the document, which is now viewed as a overly-precise specification of Steps You Take to Do X. Subtly, operating flexibility is reduced and through the fault of no one, descriptive process has become prescriptive. This is sometimes worse, because deliberately prescriptive process usually exists under the aegis of a specific person with authority, who can be personally appealed to. A calcified originally-just-descriptive process exists under the aegis of an independent document, to which people acribe an ineffable authority akin to law, i.e. one greater than any one individual and thus even more difficult to overturn or innovate against when the need arises.

Long-term effects:

At various times I've been involved in the due diligence process of potential acquisition targets. One of the most surprising findings was that in many cases, a company that was smaller than us had more formal processes, and this was cited by its own people as a major factor as to why they moved more slowly than we did, executed on fewer ideas, and ultimately ended up in a weaker market position than we were (which was sometimes why we were considering the acqusition).

At Facebook, there was a cultural resistance to process, to the point where the pattern around introducing process typically went "new process is reluctantly introduced only right before the point where things tip into chaos." Push this point as far as humanly possible, and then some, because what you receive in return is high organizational speed. If your organization has less process than another one of equivalent size, you will innovate and execute faster, taking ideas from conception to market more rapidly. Managers may need to psychologically contend with more chaos than they are comfortable with, but there is a huge difference between chaos that makes one uncomfortable and chaos that actually threatens the business. Stepping as close to the latter as possible confers one of the greatest advantages in the technology business: execution speed.

Process typically builds up at a regular and roughly constant rate. Shaping this rate is therefore key to long-term efficiency. If your company has a certain amount of process at size X and it's less than other companies of size X, you're faster, and when you're much much larger you'll have less comparative bureaucracy, and the same multipliers will apply: doing things twice as fast now while you're small helps you get things done in two weeks while your competitor needs four weeks, but once you're large you'll be able to do something in two years while your competitor takes another two to catch up. Two additional years might just mean the end of them.

---

在这里，我使用“工作流程”这个词来描述“个人或团体。为了完成一项活动而遵循的步骤”意义上的流程，以及组织的一般制度。随着一家公司的成长，有必要增加或整理工作流程。最重要的利弊权衡通常是工作流程所带来的阻力，以及效率或效益上的收益孰轻孰重。

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

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

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

影响

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

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

对协调和沟通的影响

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

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

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

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

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

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

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

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

长期影响

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

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

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

Promoting your leaders from within is relatively well-known advice for building healthy long-term organizations. It is also important for small and rapidly-growing startups, but upholding a policy of internal promotion for a hyper-growth startup is both uniquely vital and difficult due to a number of reasons:

1)Due to the inherent hyper-growth nature of the company, the organization is growing rapidly, so the need for new people is very high. Individual contributors can be sourced from the outside, but when finding leaders, closing off the external pipeline is therefore even more difficult and must be made as a conscious and deliberate choice.

2)External sourcing is often viewed as a "magical" source of perfect candidates ("there are so many possible candidates!"), but it is not. A successful manager needs to understand core elements of the company culture and values, including what makes the startup uniquely successful and what steps it needs to take next. An impressive resume or even the memory of their performance by others who worked with them in larger companies is not a reliable indicator of their ability to do this.

3)Your organization is unlikely to have enough fully-qualified internal candidates. Startups are usually populated by strong individual contributors and the leading candidates among them are typically the strongest such people, so they are (1) an immediate loss to operational capacity if promoted and (2) not guaranteed to be as skilled in management as they are at doing hands-on engineering.

However, hiring managers and executives externally is undesirable:

1)Hiring managers or executives is inherently very risky.

All hiring is ultimately a gamble. Despite interviewing and screening well, you really have no way of knowing for sure if the candidate you hire will turn out to be a dud or a superstar. When it comes to hiring engineers, the success ratio is never better than 80%. With managers and executives, it's never better than 50%.

This means that for an externally-sourced manager, you have an even chance of getting someone who might not just be no good at the job, but could be fatally bad for your organization. Getting a bad engineer is harmful, but usually not fatal - a bad manager or executive can be, and your organization may not recover.

Remember that experienced managers have also engaged in hiring, so they are usually quite skilled at sounding good in an interview.

2)There is a very high probability that an externally-sourced manager will slow you down.

This is because the primary source of experienced managers is larger companies. Small companies cannot produce many managers (there just aren't enough people to manage, or if there are, it becomes a large company), so the vast majority of managers come from large companies. There is a low probability that external managers will understand, preserve, and strengthen the internal culture. They will tend to bring their own outside culture, which is typically that of the larger company. This is the single greatest potential force that can slow down your internal operations, usually by introducing process and methodology significantly before it is optimal to do so (the reason is usually "preparing the organization to scale").

While the company or your engineering department remains below a certain size (specifically, 150-250 people, the Dunbar number), organizational culture is still nascent and is dominated heavily by the personalities of individuals and group convention. Leaders have a disproportionate effect on shaping the culture, so a single new leader can easily shift the entire organization into focusing on things which are not vital to the startup's real growth and market viability, and cause it to lose its competitive edge.

More than one startup has ended up inadvertently shooting itself in the foot when, after taking funding in an A- or B-series round, decides it should now hire a professional manager or VP to "help scale up the team." Instead, what often happens is that the team gets scaled up, processes are put into place, execution slows way down, market position falters, the manager or executive is not fired quickly enough, and the company fails to make it to the next stage.

Therefore, successfully implementing a policy of internal promotion is both vitally important but uniquely difficult to do. Here are some ways to do it:

1)Source management candidates who are willing to join as individual contributors. While the company remains below a certain size, it's is eminently possible for highly talented technology managers to join as individual contributors and rapidly rise into positions of leadership, and they should be encouraged to do so.

This is also a good sieve for finding the occasional manager who has spent time in a larger company but who can effectively manage at a small company (or be rapidly indoctrinated with enough of the culture to do so). It is also an effective acid test for technology leaders who truly possess individual technical acumen and talent (see #5: Technical Leadership, later to come), because they have the confidence to re-prove themselves over and over again. Look for people who have direct experience in a similar startup mentality, usually in the following two groups:

• managers who've started startups themselves but for one reason or another (e.g. acquisition) had an opportunity to learn how to be a professional manager in a larger company.
• managers who've worked at a startup during a phase where it was smaller than the current size of your company.

NEVER hire a manager who has never had experience working at a company as small as yours. They will be utterly unable to comprehend how to fit into or run your operations without using the lens of "we need to do this the way we did it in my experience at a larger company." This is almost certain death for your department and, if your department is engineering, your company.

2)Using either the few experienced managers you've been able to internally promote or failing that, outside executive coaches, intensely mentor your more inexperienced managers to develop their skills. Typically, because many of your management candidates were less than fully-qualified, they will demonstrate potential but still be unsure in their new roles. Until they are comfortable and practiced in their roles, both they, their peers, and their teams will exist in a state of some distress.

Special attention needs to be given to new managers, primarily in addressing ways in which they need to reach a level of comfort regarding the ambiguities of their role, their people management responsibilities, and general confidence-building. Left unattended for too long and combined with the stresses of a hyper-growth startup, it can result in failure (usually demotion or self-demotion) and a morale setback to the team.

The key trade-off that is being deliberately made here is that with proper and intense mentorship, an internal candidate with a deep grasp of company culture, leadership potential, and a track record of success in the service of company goals has a higher probability of success as a manager in your organization than an externally-sourced candidate whose true skillset, culture, and motivations are ultimately questionable.

Long-term effects:

Once the organization's size successfully passes the 150-200 people ("Dunbar") stage with its culture intact and inculcated into its operating conventions, it becomes self-reinforcing and outside managers can be gradually introduced directly into those positions without internal promotion (continuing to fill the majority of leadership positions via internal promotion is a good idea anyhow) in order to season the skills of the management cadre. The culture is now stronger than the influence of any one new manager, and will become a strong passive force in eliminating candidates who do not fit that culture, thus becoming self-reinforcing.

There is a famous set of quotes from Jamie Zawinski that talks about the difference between people who joined Netscape in "the early days" vs those who joined later. The early people joined "to make the company great," while those who joined later did so "because the company was great" and, he felt, this was key to the later lackluster performance of the company.

The motivation of those who join your company later, especially after it has achieved externally notable success (or "worse," wild financial success) are highly suspect - they are likely to be oriented around money, security, conservatism, or some combination of the three, i.e. "because the company is great" and are unlikely to share the early core values. This is undesirable, and it can be one of the things that will sap your organization's longer-term success and vitality. Executive hires prone to these motivations can be very detrimental to the types of decision your later-term company will make.

The way to combat this is to have successfully promoted and earnestly developed enough of your earliest potential leaders into leadership positions, thus creating a pipeline dominated by those who joined very early on and whom you know are there "to make the company great." New people who join can be sourced into this pipeline, forming an ongoing system that indoctrinates people with the proper values before placing them into influential leadership positions.

---

内部晋升的困难

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

• 由于公司的超速发展和组织的壮大，因此对于新鲜血液的需求也就非常大。普通员工确实可以从外部招聘，但寻找领导时，想要完全屏蔽外部渠道就变得更加困难。公司主管必须对此保持非常清醒的认识，并且经过深思熟虑后，才能下定决心不从外部招聘领导者。
• 外部渠道常常被看作是不可思议的完美人选的来源（外面有这么多合适的人选），但实际并非如此。一个成功的管理者需要理解公司文化和公司价值的精髓部分，这通常包括：是什么造就了这家新公司的不可复制的成功以及下一步应该采取哪些步骤。一份令人印象深刻的简历，或是大公司里的同事对他业绩的评价，都不足以证明他能胜任这份工作。
• 公司内部不一定有足够多的能完全胜任的内部人选。创业公司的主体人员主要由优秀的普通员工构成，而领导的候选人则一般是他们之中最优秀的。所以从前面两个原因可以看出，若提拔这些人会直接导致他们的业务能力下降，并且也不能保证他们在做管理工作时会像做技术工作时一样优秀。

从外部招聘的弊端

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

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

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

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

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

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

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

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

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

Facebook的内部晋升经验

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

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

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

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

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

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

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

长期影响

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

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

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

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

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.

---

成为任何一家以技术为导向的公司的核心前提是——它能够提供一种使人类生活得更好、更快、更有效的工具。公司的效率特别是其技术运营的效率的最佳驱动体现是公司所用工具的效率。

一次又一次，成功的浪潮席卷着拥有更高效运营结构的新型创业公司（例如Google数据中心拥有的海量计算能力，或能创建整个网站的创业公司小团队），它们的成功源于拥有先进的工具。与物理工具不同，计算机工具可以实现“杠杆效力”的反复累积，通过组合这些“杠杆效力”可以达到更高的层级。

因此，公司的工作效率，影响到你需要雇用的员工数，公司成本究竟是多少，并将直接影响公司内部产品的独创性。这意味着，你的工具团队不应该是一个由二线成员组成的“事后诸葛亮”的后勤部门。你最有才华的工程师应该用公司自己的工具来工作，并且你的公司文化要优先反映这些。编写杰出的工具并继续改善和更新它们比下一个闪光的想法更重要。

案例1

在Facebook 2005—2006年的发展中，我们根据不断增长的用户数量，聘请了与其成比例的客户服务人员。而后来当我们有1000万用户时，我们剩下的客户服务人员不到20个。在Facebook的用户数量向1亿攀升时，很明显我们不能以10倍于原有员工的数量来雇用新的员工，所以我们让内部方案团队与客户服务分析师的工作配合得更加紧密，建立了更具创新的工具和用户界面，极大地提高了我们客服部门的工作效率。今天，我们只有3倍于之前数量的员工（也就60~70），却为超过3.25亿的用户提供服务。没有外部公司、外部的现成产品，或管理咨询战略可产生如此大的员工效率。这是一个内部工具团队的作品，他们分析了目前已完成建立的工作并创建了定制方案来提高效率，方法是让电脑去做可自动化处理的部分并优化用户体验，这样分析师就可以专注于做人类最擅长的事务。

案例2

过去，我们拥有数以百计的数据库计算机（和在它们之间传播的数万数据库实例），有别于雇用很多数据库管理人员，我们只有一位数据库工程师，他编写有效的工具来管理所有的数据库计算机。如今，Facebook延续了分配少量数据工程师管理数千数据库的做法。雇用“第二数据库管理人员”是因为我们的第一数据库工程师认为她需要人员来值夜班。

继续发展你的工具和能力，将使你的公司抑制雇用运营人员的需要，让每个前线人员做得更多，这样同时改善了整体协调（少量的人员意味着协调更容易进行）并减少了开支。如今，Facebook的工程杠杆率数据意味着一个工程师在为120万用户服务，我们用户增长迅速，这个比率也在增长。但是一些Facebook的最佳工程师们一直工作在最前线，他们中的大部分人工作内容是在内部抽象和工具框架方面，这些是终端用户从未见过的，但这能大大提高他们同事的效率和能力。

如果你的公司文化优先反映了这一事项，让最优秀的工程师努力改善公司的工具是没有任何问题的。最优秀的工程师愿意去能让他们发挥最大作用的地方。

今天，在第一个互联网泡沫过去仅仅十年之后，《纽约时报》网站的划分利用了更先进的技术，让更少的人做了更多的事情，这比Web1.0时代的效率有很大提高。如果你的技术公司在今天是某个领域的领导者，那是因为你使用的技术很可能是近期才在技术领域发展起来的。如果公司文化观念中没有将内部工具视为持续的重要投资，这个公司不会永远保持领先地位。如果你不这样做，不仅你的竞争对手会将你甩在千里之外，整个市场也会抛弃你。

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.

---

所有从外部聘用的管理人员包括技术部门负责人，都必须能够编写代码，并且要达到炉火纯青的地步。如果是一家技术公司，CEO也应如此。现在有个误区就是认为编程不是高管或者经理的必备能力，仿佛只是一种花哨的打字形式。但其他专业化行业都不这样认为：银行业高管必须能够阅读资产负债表；汽车业高管则需要了解催化转换器等。

有人可能会说，技术的精通程度无法检验，因为一个杰出的管理候选人最近几年可能只关注于管理，与技术已无直接的接触。而且，一个杰出的经理可以管理一切事情。显然，这是不真实的。

当然，并不是希望候选人能用当前有限的扩展性技术创建一个大规模系统，或者在芯片集这种底层进行优化，或者能记住特定语言或框架的详细语法。但检验一个经理候选人是否具有较强的个人技术背景是合理并且可取的。当然我指的是基本技能测试，如果候选人曾经是一个称职的技术人员，他肯定能通过编程测试，包含某些简单迭代或递归算法，以及计算机基础学科中指针、散列和操作系统原理等概念题。

即使是一些门槛很低、许多人可能认为任何一个程序员都会的问题，还是有很多程序员搞不定（我并不是说能够做到这一点就意味着是一个优秀的程序员，但做不到这一点则意味着你肯定不是一个优秀的程序员）。在其职业生涯早期，他们发现自己不是优秀的程序员，但又恰好处在一个技术要求没那么严谨的组织中，因此他们能够被提拔，完全是因为他们碰巧很擅长与人打交道（或善于用人）。现在，他们中的许多人已经进入了技术管理和高管候选人的行列。此外，他们通常非常善于谈论一场精彩的比赛，听起来就像他们知道自己在做什么（否则他们也不会到那个位置）。

检验一个候选人是否具备技术实力的唯一方法是：给他们出一些简单的代码题目进行测试或者找一些他们写过的开源代码直接评估检验。不能通过测试或者没有可供验证的公开技术记录的候选人将不会被雇用。

原因是显而易见的——那就是管理者需要纵观大势，以便作出明智的决定。一个有经验但无技术背景的经理可能会有好想法，但在同等情况下，一个有类似技术背景的经理则可能有更突出的表现。换句话说，前者肯定提供不了技术领导力，如果希望你的公司成为行业的技术领导者，你的领导者首先需要具备技术。

一个没有技术型领导的“技术”公司往往会失败，原因可以归咎于以下两者或者其中之一。

1. 领导无法分辨技术人员执行的工作是否符合标准，因为在面临技术挑战时他们无法区分是技术人员执行力太差还是确实遇到了技术瓶颈。进而，也就无法实行绩效管理，这会导致业绩平庸，并将最终导致彻底甚至反复的失败。
2. 业务需求导致领导不顾技术人员的建议或者想法。当今严酷的商业环境要求企业领导推进企业不停地超越旧边界，这意味着领导不仅要告诉他的员工警惕“该死的鱼雷”，还要能够深化拓展，不能仅求安逸。不幸的是，非技术型领导人没有个人能力来衡量首要技术问题的实际风险状况（例如：某些特殊情况下已经非常过时的限制），并往往会推翻那些不应该被推翻的建议。

在Facebook之外，我见证了不止一个由于管理层缺乏核心技术力而导致的大型公司的失败。而在Facebook，个人技术能力恰巧是所有工程管理人员所必需的，甚至包括部门领导及CEO（是的，Mark Zuckerberg还在继续参与Hackathon编程活动）。这使得该公司敢于多次进行技术冒险，以达到更大的产品创新目标并实现一贯快速的前进步伐，正所谓越了解游戏规则，玩得就好。