公司影响行为的三大工具是激励、流程和文化。人们在谈论这些时往往所指不同，因此我将为每个工具提供一个例子，以确保我们达成共识（如果你认为我应该用另一个词来表达这个概念，请随意在脑海中替换那个词）。
- 让人们准时参加会议
- 激励：对迟到者扣工资
- 流程：不允许任何迟到者进入会议
- 文化：人们强烈认为准时出席很重要
- 让人们构建复杂系统
- 激励：在晋升标准中要求复杂性
- 流程：使创建工作项或执行工作项的流程变得极其繁重，以至于人们停止做简单的工作
- 文化：人们喜欢构建复杂系统，并且/或者构建复杂系统能赢得同行的尊重和/或声望
- 避免制造缺陷
- 激励：按每件合格品支付报酬，并且/或者对不合格品扣工资
- 流程：在发货前由QA检查物品并丢弃不合格品
- 文化：人们重视卓越，并极力避免缺陷
如果你阅读“老派”思想领袖的著作，许多人主张只采用文化手段，例如Ken Thompson说，要降低缺陷率，工具（在这篇文章中，我们称之为流程）不是答案，让人们关心并因此决定避免编写缺陷才是答案，或者Bob Martin说“解决软件危机的办法不是更多工具。解决办法是更好的编程纪律。”
这类夸张言论引发的情绪反应，加上反驳它们的容易程度，导致了对文化解决方案的反弹，使人们说出诸如“你永远不应该说人们需要更多纪律，而应该审视底层系统的激励”这样的话。这与10倍程序员梗及其相关评论引发的反弹类似，导致人们说出诸如速度根本不重要或程序员之间速度绝对没有差异之类的话（正如Jamie Brandon指出的，很多速度归结于关心并致力于提升速度](https://scattered-thoughts.net/writing/moving-faster/)，所以这也是对文化反弹的一部分）。
但如果我们看看可量化的产出，就会发现，即使流程和激励是公司应该首先使用的工具，文化也有很大影响。例如，看看制造业的缺陷率，一些国家在几十年的时间尺度上1持续拥有比其他国家更低的缺陷率，这通常跨越不同公司，即使公司在多个国家运营工厂，并尽可能将相同的流程和激励导入每个工厂，由于影响人们工作方式的文化差异，情况也是如此。
回到编程领域，Jamie关于“加速前进”的文章指出：
真正有帮助的核心因素是发自内心地渴望更快。
早期我确实更在意写出“优雅”的代码，或者使用时髦的工具，而不是真正解决问题。也许这不是明确的想法，但从我的行动中能看出这些优先级。
我可能也没意识到原来可以快这么多。职业生涯初期，我身边都是和我一样慢吞吞、缺乏经验的人。
慢慢地，我开始注意到有些人能产出我穷尽一生都无法企及的项目。我想弄明白他们是怎么做到的，这意味着要放弃我原有的信念，去探索真正有效的方法。
我很幸运，职业生涯的起点是截然不同的体验——我的第一份全职工作在 Centaur，那家公司当时效率极高、产出惊人。可以说，我后来只在一个团队见过类似的生产力水平，那就是我现在的团队。不过，我现在的团队在科技公司里相当罕见（比如，团队中位数级别是“资深员工”）2。在高效率公司开始职业生涯的一个副作用是，我通常觉得大公司的开发节奏太慢，而且我认为没有理由仅仅因为“慢是常态”就放慢脚步。我经常听到大公司里那些曾在非混乱但也不算特别快的初创公司工作过的人，发表类似的评论。某家最时髦的公司定期进行的一项调查会问：“你觉得自己的开发速度比以前的公司快还是慢？”结果呈现双峰分布，取决于受访者来自小公司还是大公司（在这家时髦公司，开发速度比初创公司慢，但比大公司快）。
有一个故事，如果我没记错的话，是布莱恩·伊诺讲的。他当时在练习计时训练，目标是反复练习，直到能在平时用时或更短的时间内完成特定任务。但他很难达到自己的正常时间，对自己比平时慢感到恼火，于是坚持练习直到达成目标。这时他才意识到自己记错了目标，无意中设定了一个新的个人最佳时间，比他原本认为可能的还要好。虽然简单地说“只要用心就能做到任何事”过于轻率，但我们几乎没有人能接近自己的潜力，而我们认为自己能达成的目标往往是主要的限制因素。当然，在极限情况下，速度和质量之间存在权衡，你不能“免费”获得速度，但在编程方面，我们离帕累托前沿还远得很，只要意识到这些“免费胜利”的存在，就能轻松获得。
文化影响这一点的一个方式是，人们常常从所处的文化中吸收关于“什么是可能的”观念。举一个非速度相关的例子：我参加RC后注意到，在Deconstruct和Strange Loop等备受尊敬的非学术、非企业技术会议上，很多演讲者也参加过RC。大多数人在参加RC之前从未做过演讲，当我问起时，很多人其实一直想演讲，但没意识到成为“大型”会议演讲者的过程有多简单（想个点子，写下来，然后提交你的提案）。事实证明，在会议上做演讲很容易，对许多人来说，主要障碍就是不知道这件事是可行的。在一个很多人做演讲、且犹豫不决的人询问如何开始时被告知“这很简单”的环境里，很多人最终都会去演讲。写博客也是如此，这就是为什么大量广受欢迎的编程博主中，有不成比例的一大部分是在参加RC后才认真开始写博客的。对许多人来说，开始写博客的障碍在于：意识到写博客是可行的，以及从技术角度看，只要随便选个半合理的工具链并完成设置，开始写博客就非常容易。然后，因为人们做演讲、写博客，他们在这方面越来越擅长，所以平均而言，RC的校友可能比随机程序员更擅长演讲和写作，尽管RC几乎没有技能传授或指导。
另一种文化能够显著驱动技能发展的领域是高度依赖态度的技能。调试就是一个例子。正如朱莉娅·埃文斯所指出的，良好的态度是调试效率的关键因素。这正是Centaur公司非常擅长培养员工的一点，以至于在我所在的Centaur部门中，几乎每个人按照科技公司的标准都会被视作非常出色的调试者。
在大型科技公司，常见的情况是人们在尝试几种随机方法失败后就会放弃调试bug。一个极端的例子是，我在一家市值数百亿美元的科技公司认识的人曾表示，花超过几个小时去调试一个bug毫无意义，因为工程师的时间太宝贵，不能浪费在需要更长时间解决的bug上——这种态度是他从最初加入的团队学来的。持有这种调试态度的人，除非改变观念，否则很难成为优秀的调试者。而许多人，包括这个人，都会将第一份工作中学到的态度和习惯长期保留下来3。
按照科技行业的标准，Centaur是另一个方向的极端案例。如果你在设计CPU，遇到一个无法理解的bug就放弃是不可接受的。即使bug的症状不严重，其根本原因可能非常严重，而更严重的症状只有在芯片出货后才会显现，因此即使是看似微不足道的bug也必须追查到底。此外，很多bug根本没有良好甚至确定性的复现方法。复现步骤往往是这样的：“在系统上使用这些设置运行这些程序，几小时或几天后系统会死机和/或数据损坏。”调试这类bug时，会遇到无数错误方向和死胡同，有些可能耗费数周甚至数月。作为一名新员工，看着同事们处理这类bug时，我观察到的是他们日复一日地追踪这些bug，既不沮丧也不放弃。当这种文化成为常态，周围每个人都持有这种态度时，你自然也会接受同样的态度。此外，大量实用的调试技能来自于解决过许多问题后积累的战术技巧，而这自然源于花足够时间以积极态度调试问题，尤其是接触过困难的调试难题。
当然，科技公司的大多数bug并不值得花费数月时间，但有意放弃一些不值得修复的bug，与因从未调试过严重bug而缺乏调试能力、最终连最简单的bug都无法解决，这两者之间有着天壤之别。
文化态度的影响远不止调试这样的个人技能。在Centaur，人均严重生产故障率是我工作过的所有公司中最低的，大约100名工程师每年发生的严重故障远低于1起。相比之下，我从未在规模不到其十分之一的团队中，见过低于10倍于这个比率的严重生产问题。和大多数初创公司一样，Centaur的流程非常精简，激励措施也远比我待过的大型科技公司薄弱。
其中一个原因是，公司内部有一种“问题归属”的文化，无论你属于哪个团队。如果你发现问题，就会去修复；或者，如果有非常明确的责任人，你会告知他们问题，而他们会去解决。这里没有路线图、站会、看板或其他任何推动人们处理重要问题的机制。人们无需提醒或催促就会主动去做。
这与我在三家大型科技公司中的两家所见截然相反——在那里，大多数人像躲避瘟疫一样回避自己团队职责范围之外的问题。一个不懂政治手腕的人向其他团队提出问题，得到的默认答复是：“抱歉，这不在我们本季度的路线图上，也许我们可以把它列入[两个季度后]的路线图。“而两个季度后，那些天真到再次提出同样问题的人，会得到完全相同的回应。在我工作过的每一家科技公司，巨大且代价高昂的问题总是不断被忽视，因为没人愿意接手。在Centaur，我从未见过这种情况。
大型科技公司文化的一个副作用是：那些真正想做正确事情的人，只要愿意无视组织流程和激励，就能轻松完成影响力极高的（正面）工作——只需四处走动，解决任何实习生都能处理的问题。你随便一伸手，就能碰到一个对公司价值超过我一生预期收入的问题，而且每年轻松解决好几个这样的问题。当然，导致这么多简单问题得不到解决的相同力量，也意味着解决这些问题的人不会因此获得回报4。
相反，在Centaur的八年里，我只发现了一个微不足道的问题，其修复价值超过了我一生的收入，因为通常问题在发展到那个程度之前就已经被解决了。我曾见过大公司试图通过激励措施（例如，为解决重要问题提供金钱奖励）和流程（例如，制作一个包含所有项目/问题的巨型列表，大约1000个项目，由一个人排序，并配合官僚体系，要求所有人通过JIRA不断更新进展，以便项目经理能持续向负责统筹数千名工程师工作的人发送进度更新5）来解决这个问题，但这些尝试的效果都不及建立主人翁文化的一半（公平地说，我听说Facebook用金钱奖励取得了不错的效果，但我三次都没通过Facebook的面试，所以无法亲自观察其运作方式）。
另一个导致严重错误率相对较低的因素是，在Centaur，整个公司对质量的重视程度，是我在大型科技公司的团队层面甚至组织层面都从未见过的。当你拥有一群关心质量、认为任何问题都不容忽视的人时，质量自然就会产生。而在招聘新人时，只要扩张速度不至于让文化被新员工冲淡，他们往往会养成同样的习惯和价值观，尤其是在招聘应届毕业生时。虽然这并不常见，但确实有不少小型公司拥有追求卓越的文化，这种文化通常无需繁重的流程或巨大的激励就能持续存在。然而，这在大型科技公司行不通，因为它们都经历过高速增长期，在此期间，维持这种（按主流标准来看）极端的文化价值观是不可能的。
到目前为止，我们主要讨论了公司如何向人们传递文化，但我觉得同样重要的是，当人们离开时，他们会如何带着这种文化继续前行。自从我从硬件转行到软件后，我一直相当成功，我认为，在我能控制的因素中，最大的一个是我从第一份全职工作中汲取了有效的文化价值观，并继续以同样的方式行事，这非常高效。我也在其他一些人身上看到过这种情况——他们在职业生涯中“成长”于一种卓越的文化中，然后转行到另一个直接技能迁移更少的领域，比如从滑雪转到土木工程。与此相关的是，如果你阅读那些讨论自己为何在领域内非常高效的人写的书，比如布莱恩·伊诺斯的《实用射击》、丹·瑟林的《为赢而玩》等，这些书往往包含相同的核心思想（认真观察和改进技能、避免情绪自我破坏的重要性、直觉的重要性等）。
总之，我认为文化价值观和技能的传递是选择工作时被低估的一部分（我觉得被高估的因素包括声望和普遍声誉），人们应该慎重考虑自己身处何种文化，因为很少有人能完全避免至少在一定程度上吸收周围的文化价值观6。
虽然这篇文章以科技为导向，但这并非科技领域特有的现象。一个经典的例子是，理想主义的学生进入法学院时，本意是从事“拯救世界”之类的工作，但随后吸收了周围学生中通过声望传递的文化价值观，最终去追求他们能得到的最有声望的工作——如果不是书记员职位，那就会是“大律所”的工作，这与“拯救世界”完全相反。粗略估计，每个人都认为“这绝不会发生在我身上”，但从我观察到的许多人加入那些他们最初觉得价值观和文化非常不对劲的组织来看，几乎没有人能在不某种程度上吸收周围价值观的情况下坚持下去；很少有人能忍受周围所有人都因为他们持有“错误”的价值观而把他们当傻子看。
附录：湾区文化
我欣赏湾区的一点，是人们那种试图改变世界的态度极具感染力。在我住过的所有地方，人们都会抱怨问题（比如按揭行业糟透了、卖房流程繁琐等）。在湾区以外，这些抱怨就只是抱怨；但在湾区，如果一年前我听到某人抱怨某件事，一年后再聊起来，他们很可能已经创办了一家初创公司，试图解决他们抱怨的问题之一。我并不认为湾区人本质上与其他地方的人不同，更多是因为当你身边都是愿意放弃工作去颠覆一个根深蒂固行业的人时，做同样的事就显得相当合理（这也会带来网络效应，从“技术”角度让事情更容易，比如更容易融资）。这类抱怨和试图解决问题的真诚态度很容易被嘲笑，但那种真诚是我非常钦佩的。
当然，并非所有湾区文化都是积极的。湾区尤其以出了名的放鸽子文化而闻名，我刚搬去时对此感到震惊。在那里待了没多久，有一次我和几位老朋友约好吃饭，发短信告诉他们我会晚到大约15分钟。他们在我出现时很惊讶，因为他们以为我说要迟到其实意味着我不会来了（另一个让我惊讶的更极端的规范是，对很多人来说，在计划开始前不久没有确认，就意味着这个人取消了，也就是说，计划默认是取消的）。
另一个我常听人抱怨的相关规范是，管理层和领导层会为了“取悦他人”而避免冲突，对所有事情都说“好”，这实际上增加了冲突，因为那些把“好”理解为“是”而不是“我说好是为了避免说不，但并非真心同意”的人，后来会惊讶地发现“好”其实意味着“不”。
附录：Centaur的招聘流程
当我谈到Centaur时，人们有时会评论说，他们一定采用了某种极其严格的招聘流程，从而招到了精英工程师。但实际上，招聘流程远没有我工作过的任何“名牌”大科技公司（谷歌、微软和推特）那么挑剔，也明显不比我工作过的传统老牌公司（IBM和美光）更挑剔。“一个奇怪的诀窍”在于入职培训，而不是招聘。
在新人招聘方面（按比例来说，我们招了很多应届生），招聘难度比我待过的任何一家公司都大。高级职位招聘并不难，因为Centaur在奥斯汀本地口碑不错，但应届生中没人听说过我们，也没人愿意来工作。我在招聘会上招人时，得站在展台前主动拦住路过的人，才能让人愿意跟我们聊几句。这意味着我们没法在面试环节挑三拣四。大约在Jeff Atwood那篇极具影响力的文章《为什么程序员不会编程？》（以下加粗部分是他的原话）流行起来、宣扬“大量假程序员在求职，不用基础编程题筛选就会招到不会编程的人”这一观点时，我们正大幅扩招应届生：
我感到震惊和愤怒，任何所谓的程序员竟然会连最简单的程序都写不出来就去应聘工作。这对所有以写软件为生的人来说简直是侮辱。……为了拥有面试真正会编程的程序员的奢侈**，不得不做这么多预筛选，真是可悲。如果这还不算令人沮丧，那什么才算？
由于我们是一家偏重编程的硬件公司（验证工程师主要写软件，设计工程师写大量工具），我们尝试问一个简单的编程题：要求应聘者根据描述写出计算斐波那契数列的函数（朴素解法即可，不需要线性时间或更快的解法）。但我们放弃了这道题，因为没人能在不全程详细引导的情况下做出来——这意味着这道题对我们毫无区分度。
尽管我们没怎么问编程题，但员工们却写出了复杂的并发代码（内部处理器微码，常用屏障作为并发控制机制），并以比我在其他任何公司都高的效率和更低的缺陷率创建了各种工具。
我们避开主流招聘方式反而效果更好，因为这意味着我们尝试并成功招到了其他公司不争抢的人才。如果其他公司使用的招聘技巧非常有效，那这种做法就不合理了——但其他公司做的不过是让人写FizzBuzz，再在白板上画些算法。虽然有人可能认为算法面试能招到能解面试题的人，但事实并非如此。我们的另一个做法是比大多数公司更少使用“名校光环”筛选，这也让我们招到了其他公司根本不会考虑的杰出工程师。
我们确实遇到过一些不合适的人，但从来不是因为他们是“所谓的程序员”，连“最简单的程序”都写不出来。我知道两起“雇佣了根本不会编程的假程序员”的案例，但这两起都发生在知名公司，这些公司的编程面试在科技行业中属于最严格的那一类。其中一起，公司很快发现此人不会编程，于是调出面试时的监控录像，发现来面试的人和实际入职的人不是同一个。另一起，此人成功在谷歌潜伏了多年，直到有人意识到他从未真正写过代码，任务都是让别人完成的。发现问题的这个人最终安排了一次结对编程，结果发现此人连循环都不会写，分不清=和==的区别，尽管他在谷歌当了多年的“高级软件工程师”（L5/T5）。
我并不是说编码面试永远不会帮你避免雇佣假程序员，但假程序员的比例似乎非常低，以至于一家小公司可能十年不设编码问题也不会招到假程序员；而那些被骗子盯上的大公司，即便设置了编码问题，也依然难以完全避免。
附录：文化输入
虽然这篇文章主要讨论公司文化如何影响员工，但员工当然也会影响公司文化。在招聘中，尤其是高级管理层和高级个人贡献者，他们如何影响文化这一点似乎被低估了。我多次近距离或远距离观察到，新招的高级人员会将自己的文化带入公司，而这种文化与现有公司文化不兼容，导致严重问题，并常常引发高离职率，直到局面稳定下来。
如今我工作多年，参与过多次高级职位的招聘讨论，但除了那些极其明显的问题——比如面试中表现出粗鲁、种族歧视或性别歧视——我从未见过有人提出候选人是否会带来不兼容的文化价值观。
感谢Peter Bhat Harkins、Laurence Tratt、Julian Squires、Anja Boskovic、Tao L.、Justin Blank、Ben Kuhn、V. Buckenham、Mark Papadakis和Jamie Brandon的评论、修正和讨论。
- 哪些国家真正拥有低缺陷率的制造业，往往与公众普遍认知大相径庭。要看清这一点，你必须查看数据，而这些数据通常受保密协议约束，一般只在“酒吧闲聊”中流传。[返回]
- : Centaur曾拥有我有时称之为“世界上最愚蠢的商业模式”——从1995年开始与英特尔在x86芯片领域竞争，因此它需要极高的生产力才能生存。在艰难岁月里，AMD通过出售自身部分业务来维持x86开发，而其他所有竞争对手（Rise、Cyrix、TI、IBM、UMC、NEC和Transmeta）都被淘汰出局。如果将Centaur与存活最久的倒闭竞争对手Transmeta相比，Centaur的出货速度明显更快，这是Centaur能存活到2021年（被英特尔以伪收购式招聘吸纳）的主要原因，而Transmeta在烧掉约10亿美元资金（包括诉讼赔偿）后于2009年倒闭。Transmeta成立于1995年，2000年才推出首款芯片，这在当时被视为新CPU/微架构开发的正常节奏；Centaur于1997年推出首款芯片，并保持高频率出货直到2010年左右（至于公司如何逐渐放缓直至停滞并被收购式招聘，则是另一篇文章的话题）。[返回]
- 此人最初认为第一个团队的流程和价值观荒谬至极，直到认知失调发挥作用，他成为公司文化的坚定拥护者——这在新加入一家显然存在糟糕做法的公司的人中很典型。[返回]
- 这说明了激励与文化并非相互独立。在我所见过的那些不奖励此类工作的地方，由于文化原因，做出这类高影响力变革往往需要令人筋疲力尽的苦战，而最终却毫无回报，这导致那些倾向于主动解决问题并从事高影响力工作的人员流失率更高。在这种环境中，我观察到的是，环境会差异化地留住那些不愿主动承担责任的人，这反过来又让试图解决严重问题的新加入者面临更大困难，更容易导致倦怠。[返回]
- 我添加这条注释是因为，当我向人们描述这种情况时，许多人认为这一定是讽刺。但这不是讽刺。[返回]
- 与许多其他特质一样，公司内部以及公司之间都可能存在巨大差异。例如，在我曾工作过的一家公司里，有一个团队对客户服务的理解与公司大部分部门截然不同，而加入该团队且没有迅速离开的人通常会吸收他们的价值观。
公司里大多数团队对内部客户态度友好，但这个团队却秉持着“客户永远都是错的”的态度。一个有趣的副作用是，当我与这个团队打交道时，得到最佳支持的时机，恰好是那些尚未被团队文化同化的初级工程师值班的时候。有时高级工程师会说某件事不可能或不可行，结果初级工程师跟进后却轻松解决了问题。