打造文化（Bootstrapping Culture）

当你担任高级工程领导时，你的职责之一就是为你的部门设定文化。首次担任首席技术官（CTO）的人常见的一个失误，是低估了对工程团队文化保持清晰、深思熟虑的重要性。无论你是在培养一支新团队，还是在改造一支现有团队，忽视团队文化都是让工作变得更加困难的必然途径。随着团队的成长和演变，像对待你依赖的任何其他重要基础设施一样去关照你的文化，是很重要的。

在 Rent the Runway，我有机会搭建工程团队文化的许多要素。因为我加入时，团队仍然运行在经典的、无结构的「草根创业公司（scrappy startup）」模式上，所以我能够把许多文化结构和实践引入团队及其成员之中。这个过程对我来说是一次极好的学习经历。

对于许多被创业文化吸引的人来说，「结构（structure）」和「流程（process）」的想法被视为最坏也是有害的，最好也不过是无意义的。我见过对创业团队的调查，其中引入结构的想法引发了诸如「缓慢」和「扼杀创新」之类的反应。这些受访者认为，结构是大公司行动迟缓、滋生官僚主义、对聪明人来说普遍无聊的原因。

与怀疑者谈论结构时，我试着重新框定讨论。我不谈结构，而谈学习（learning）。我不谈流程，而谈透明度（transparency）。我们建立各种体系，并不是因为结构和流程本身具有内在价值。我们这样做，是因为我们想从成功和错误中学习，并以透明的方式分享这些成功、把从失败中汲取的教训编码下来。这种学习和分享，正是组织随着时间推移变得更稳定、更具可扩展性（scalable）的方式。

我希望帮助你形成一套关于公司文化的个人哲学，同时给你一些建立流程和结构的方法。如果你想创建健康的团队，你需要清楚什么对你自己、对你的公司、对你不断壮大的同事群体是重要的。不仅要考虑你在乎什么，还要考虑随着公司和团队的成长演变，你如何有效地扩展（scale）这些知识和努力。你会尝试各种结构和流程并向它们学习，但如果你没有一个基本理论可以去检验，不打算去证明或推翻关于该理论的假设，那么学习就很难进行。所以，让我们用科学的方法来做这项创造文化的练习，看看你如何以合乎逻辑的方式来思考你可能需要的文化要素。

早期的创业公司吸引的是那些能够处理极高程度不确定性和风险、以换取同等高度操作自由度的人。无论这个想法在纸面上看起来多么强大，都没有长期保证公司会成功，甚至保证它会长期存在。市场往往是未经证明的。有些迹象看起来不错，有些迹象看起来很糟。可能面临来自大大小小的其他公司的激烈竞争。此外，几乎没有什么既有的工作可以在此基础上构建。代码尚未写出。业务规则尚未建立。很难夸大在创业公司的背景下需要做出多少决策，即使是一家已经发展了几年的公司。从决定技术框架到决定办公室装饰，一切都可以争夺。

这些最初的决策中，有许多在尘埃落定之前会被推翻好几次。人们很容易想到更换一个未能随公司技术需求扩展的框架，但像休假政策、核心办公时间，甚至公司价值观之类的东西，在创业公司的头几年里都可能发生变化和演变。

在那些早期日子里，领导者最需要愿意做的事情——而且领导者（leaders）通常包括公司里的每个人，而不仅仅是创始人或高管——是选定一个策略并坚定执行。在大量选项面前培养果断力。你有问题？找出解决方案并解决它。那个方案不管用？试试别的。你不需要找到完美的解决方案；你需要找到能让你撑到下一个里程碑的东西，无论那个里程碑是下一个版本发布、下一轮增长、下一轮融资，还是下一次招聘。

有时公司会决定限制决策本身，比如放弃头衔的组织。没有头衔在一种意义上是决策，但在另一种意义上，这个决策意味着你永远不需要决定某人的头衔是什么，你不需要担心把人晋升到新的头衔，你也不需要建立起将来为头衔做决策的机构，因为你已经把那个选项移除了。决定暂时不做决定，是新公司的一个流行选项，因为在只有几个人的规模下，这真的无关紧要。

关于组织政治最伟大的文章之一，是乔·弗里曼（Jo Freeman）写的一篇题为《无结构的暴政》（The Tyranny of Structurelessness）的文章。虽然这篇文章写的是早期女性主义/无政府主义集体，但弗里曼的洞见同样适用于创业文化。假装缺乏结构，往往会由于人类沟通的本性以及试图扩展这种沟通的挑战，而创造出隐藏的权力结构。有趣的是，弗里曼描述了一组无结构群体事实上可以正常运作的情形：

它是任务导向的（task oriented）。 它的职能非常狭窄、非常具体，比如办一场会议或出一份报纸。正是任务在基本层面上结构化了这个群体。任务决定了需要做什么以及何时需要做。它提供了一种指引，人们可以据此判断自己的行动并为未来的活动制定计划。
它相对较小且同质（homogeneous）。 同质性是确保参与者拥有互动「共同语言」所必需的。来自截然不同背景的人可能会为意识觉醒小组增添丰富性，每个人都可以从他人的经验中学习，但任务导向群体中成员之间的差异过大，只意味着他们会不断地误解彼此。这样多样化的人对言语和行动的解释不同。他们对彼此的行为有不同期望，并根据不同标准评判结果。如果每个人都足够了解其他人、能理解那些细微差别，那么这些差异可以被容纳。通常，它们只会导致混乱，以及无尽的时间花在理顺那些没人想过会出现的冲突上。
它有高度的沟通（communication）。 信息必须传递给每个人，意见要被核查，工作被分配，参与相关决策得到保证。这只有在群体很小、人们在任务最关键阶段几乎生活在一起时才可能实现。不用说，让每个人都参与所需的互动数量，会随参与者数量的增加而成几何级数增长。这不可避免地会把群体参与者限制在五个人左右，或者把某些人排除在某些决策之外。成功的群体可以大到 10 或 15 人，但只有当它们实际上由几个执行任务特定部分的较小分组组成，且这些分组的成员彼此重叠，使不同分组在做什么的知识容易传递时才行。
它的技能专业化（skill specialization）程度低。 不是每个人都必须能做所有事，但每件事都必须有不止一个人能做。这样就没有人是不可或缺的。在某种程度上，人们变成了可互换的零件。

这里弗里曼描述的，是许多早期创业公司的常见情景。即使整个公司发展得超出了小群体的规模，工程团队也常常强迫自己保持无结构。招聘「全栈（full stack）」工程师——且这些工程师完全来自当前团队的专业和社交网络——导致低技能专业化和高度同质化。强迫团队集中办公降低了沟通障碍。而也许最关键的是，让工程团队仅仅作为产品或创始人的执行臂膀运作，使团队高度任务导向。

我敢打赌，有些人会对这种对常见创业公司技术组织的描述感到不悦。毕竟，这些工程团队往往是公司里薪水优厚的宠儿！即便如此，无结构的组织要么表现出一些最终使它不如成员们愿意相信的那样自主的特征，要么由隐藏的等级制度和权力动态所统治。在许多情况下，两者在某种程度上都是真的。

无结构团队的例子也适用于技术决策和流程。早期创业公司里经常发现大量意大利面条式代码（spaghetti code），这是有原因的。当工作是为了满足眼前的任务而完成、在一个由一群可互换者共同维护的统一代码库里进行时，结果通常不是一个更大的深思熟虑的结构，而是这里修修补补、那里 hack 一下——只要能推动事情前进就行。毫不奇怪，当我们想让代码可扩展时，通常最终要重构意大利面条式代码，因为重构通常涉及识别并明确地勾勒出结构，以使代码库更易读、更易在其上工作。

简而言之，这就是结构的价值。结构是我们扩展、多样化、承担更复杂的长期任务的方式。我们对软件这样做，对团队这样做，对流程也这样做。正如强大的技术系统设计者能够识别并塑造底层系统结构一样，强大的领导者能够识别并塑造底层的团队结构和动态，并且以一种支持团队长期目标、让每个个体都能发挥最佳状态的方式来做这件事。

没有什么比一个带有僵化等级制度的小团队更荒谬的了。我们都会觉得，一个五人团队——第五人向第四人汇报，第四人向第三人汇报，第三人向第二人汇报，第二人向第一人汇报——相当奇怪，而且可能没有必要。同样，如果一家挣扎中的企业里的五人团队把大部分时间花在开会决定卫生间该储备哪种卫生纸上，他们的优先级就似乎错位了。结构可能来得太早，并通过拖慢一个本应专注于其他事情的群体而造成伤害。

然而，在小公司里更常见的是结构来得太晚。问题会悄悄蔓延。一个人习惯了做所有决定，并频繁改变主意。当只有他和另外几个人时，这种策略运作良好。但当他对 10 人团队、20 人团队、50 人团队继续这样做时，你开始看到的是高度的混乱和浪费的努力。他改变主意的代价变得越来越昂贵。

我听过的最好的创业领导力类比之一，来自一个朋友，On Freud，他曾在几家不同的创业公司从事工程管理。On 把最早的创业公司比作驾驶赛车。你离地面很近，能感觉到自己的每一个动作。你有控制力，可以快速转弯，感觉一切都在飞速前进。当然，你也随时有撞车的风险，但如果你撞了，拖下水的只有你自己。随着你成长，你升级为一架商用航班。你离地面更远了，更多人的生命依赖于你，所以你需要更仔细地考虑你的动作，但你仍然感觉在掌控之中，可以相对快速地转向飞机。最后，你升级为一艘宇宙飞船，在那里你不能快速移动，航线早已设定，但你能飞得非常远，并带着大量的人一起踏上旅程。

评估你的角色（Assessing Your Role）

认清你所驾驶的船（vessel）有多大。这由公司人数、公司年龄、现有业务基础设施（软件、流程等）的规模以及风险承受能力（risk tolerance）共同决定：

人（People）

人越多，你就越需要深思熟虑的结构来让每个人都朝着正确的方向前进。希望对组织保持高度控制的领导者，往往需要更多的结构来确保他们的意愿得到执行。现代公司往往把结构重点放在目标设定上，而不是试图从顶层做出所有决策，但不要低估成功设定和传达目标所需的结构。

年龄（Age）

公司存在的时间越长，习惯就越根深蒂固。另一方面，公司存在的时间越长，它就越有可能继续生存下去。

现有基础设施的规模（Size of existing infrastructure）

如果你几乎没有既定的业务规则（比如「这就是我们决定向客户收取多少费用的方式」），也几乎没有代码或物理基础设施（如门店、仓库或库存），那么对结构的需求就较少。另一方面，你拥有的既有业务规则和基础设施越多，你就越需要清楚如何处理它们。

风险承受能力（Risk tolerance）

你所在的行业监管严格吗？如果犯了某些类型的错误，你会失去很多吗？还是你处于一个不受监管的行业，没什么可失去的？你的结构和流程应该反映这一点。一般来说，依赖你的人越多、业务规模越大，即使没有监管要求，你愿意承担的风险也越少。

结构随着公司的成长和老化而增长。事实上，甚至有一条定律可以解释这一点，来自约翰·高尔（John Gall）的著作《系统学》（Systemantics）：1

一个运转正常的复杂系统，总是被发现是从一个运转正常的简单系统演变而来的。一个从零开始设计的复杂系统永远不会运转，也无法通过修补让它运转。你必须从一个运转正常的简单系统重新开始。

你的公司是作为一个包含几个人的非常简单系统起步的，随着越来越多的人、规则和基础设施被加入，它演变成了一个复杂系统。我认为，当你的团队很小且运转良好时，过度设计团队结构或流程并没有多大好处。然而，在某个时刻你会开始经历失败，而失败是调查和识别你的结构需要在哪里改变的最佳场所。在创建职业阶梯（career ladder）的例子中，一个人因为缺乏职业路径而离职，可能不足以推动你创建职业阶梯，但当多个人离职或拒绝加入时，你可能会重新考虑。你需要权衡缺乏结构给团队带来的价值，与失去那些你本可能想雇佣的人的代价。

我给领导者的建议很简单：当失败发生时，审视导致这些失败的现实的所有方面。你看到的模式，就是发展你的结构的机会——无论是创建更多或不同的结构，还是移除结构。想想失败发生的频率及其代价，用你最好的判断来决定需要做出哪些改变。用失败来引导演变，让你能在合适的层级应用结构。如果失败只发生在系统的一个部分——比如说，在一个团队里——你可以尝试解决那个团队的结构，而不必改变更大的结构。那么审视成功呢？嗯，你确实可以从成功中学到东西，但它往往是一位糟糕的老师。讽刺的是，虽然运气在失败和成功中都起作用，但我们常常把失败归因于坏运气，把成功归因于自己的行动。正如高尔定律所说，一个运转正常的简单系统可以演变成复杂系统，但这并不意味着把从成功的复杂系统中汲取的教训应用到别处，就能让你复制那份成功。作为人类，我们倾向于把失败归咎于坏运气，直到无法再忽视自己对失败做出的贡献为止。因此，我们不太可能基于失败的教训过度结构化我们的团队。而成功，则用银弹诱惑我们——那个能让一切都变好的奇怪诀窍。如果你想从成功中学习，请确保当你更广泛地应用那些教训时，你能识别出你真正寻求的实际改进，并且你理解重复那份成功所需的背景环境。

公司的年龄和团队的规模在这个问题上起作用。如果你在一家已经存在了一段时间、并且还会继续存在一段时间的公司，那么用结构（增加或移除）来提高效率是非常有帮助的，即使实施起来需要一些前期成本。这就是诀窍的一部分。学习很少是免费的。分析情况、思考好的心得需要时间。如果你未来时间的价值低于当前时间的价值，那么你可能不会太担心节省未来的时间。仅仅因为你的公司大、老、稳定，并不意味着你可以拥有任意多僵化不变的结构。技术变革往往使以前有风险的动作变得比缓慢的替代方案更安全。软件发布频率就是一个很好的例子。长期以来，频繁发布软件既困难又昂贵，主要是因为你要把软件交付给用户。在现代 SaaS（软件即服务）世界里，bug 可以轻松修复，发布一个 bug 所涉及的风险，远低于不能足够快地扩展功能以跟上竞争的风险。正是这种对旧结构的无条件依恋，让许多人对采纳结构犹豫不决。但如果你在需要时不采纳结构，事情也会出错。

当每个新员工都因为没有入职流程（onboarding process）而拖慢团队好几个月时，那就是缺乏结构导致的失败。当人们因为没有晋升或职业成长的路径而经常离开公司时，那就是缺乏结构导致的失败。当第三次因为有人直接登录数据库、意外删掉一个关键表而导致生产故障（production outage）时，那就是缺乏结构导致的失败。我之前说过，我更喜欢谈学习和透明度，而不是使用结构这个词，因为这里我们真正谈论的是识别失败的原因，尤其是频繁失败的原因，并试图找出我们能改变什么来解决这些失败。这从根本上说就是关于学习。

创造你的文化（Creating Your Culture）

文化（culture）就是事情如何被完成，而人们无需去想它。
——弗雷德里克·拉卢（Frederick Laloux），《重塑组织：创建受人类意识新阶段启发的组织指南》（Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness）

文化是打造创业公司时经常讨论的话题。公司的核心价值观是什么？公司文化是什么样的？新员工是否「文化契合（culture fit）」？「文化契合」是否是歧视性招聘实践的狗哨（dogwhistle）？

我坚信的事情之一，是文化是真实存在的；它也极其重要，而且它是许多完全不理解的东西。它既是你公司演变的自然、容易的产物，也是如果你不加以照料就会迅速变成问题的事物。有意识地引导团队的文化是领导者工作的一部分，而要做好这一点，你首先需要理解它意味着什么。

那么什么是文化？文化是一个社区通常不成文的共享规则。例如，美国文化规定我们以握手作为问候，而在某些其他文化中，触碰陌生人被认为非常奇怪。你称呼不同地位或与你有不同关系的人的方式，是你文化的一部分。文化并不意味着每个人都持有完全相同的价值观，但它往往引导一种普遍的共识，并创造出一堆互动规则，如果你深深融入那种文化，你就不必多想这些规则。

人们确实会使用文化价值观以外的方法做决定。例如，他们可能遵守正式或非正式契约的标准。他们可能做纯粹的数据驱动分析，确定最优结果。但在群体的需求必须凌驾于个体需求之上的复杂环境中，文化价值观是使我们能够在面对不确定性时作为团队协作、做出决策的粘合剂。这就是为什么弄清楚并引导你的文化，是打造成功公司如此重要的一部分。

如果你正在组建一家新公司，没有任何保证会自然产生一个预先确定的健康文化。你可能希望你能创造一个计划好的社区，一群志同道合的人会团结起来，创造出这个伟大的工作场所和产品。但现实比这混乱得多。现实更像一场生存竞赛，文化只是事后才想到的，或者是一种事后合理化。早期员工将塑造文化，无论好坏——或者很可能是两者的混合。

不是每个人都能融入每家公司。你越早意识到这一点越好。有时我们害怕拥有核心价值观，因为我们相信它们会造成歧视。我认为，一套深思熟虑创建的、真正算得上价值观的价值观，应该会减少科技公司里经常发生的那种表面歧视，转而创建一个共享核心原则和沟通方式的真实员工社区。创建一个能让更广泛的人进入你社区的文化，对你有利。「毕业于麻省理工学院的工程师」不是一种文化。「重视技术创新、努力工作、才智、科学流程和数据的人」可能是。前者只允许人类中一个极其狭窄的子集成功通过。后者允许更广泛的人契合，同时确保那些人确实拥有相同的价值观。

如果你进入一家拥有核心价值观的公司，那些价值观很可能是由创始人，或创始人和早期员工创造的，因此它们反映了公司的文化。理解这一点很重要，因为无论你是否意识到，你都会被用这些价值观来衡量。创始团队的价值观会在公司内部被强化、认可和奖励。我的经验表明，真正拥抱并展现公司所有核心价值观的员工，往往会自然而然地表现出色。契合对他们来说很容易。他们可能会压力过大或工作过度，但他们很受欢迎，通常也很开心。那些不能那么容易匹配所有这些价值观的人，会过得更艰难。这并不意味着他们会失败，但他们会遇到更多摩擦，融入和被接受可能感觉像更多的工作。

这如何适用于你？如果你是一位技术高管、联合创始人或首席技术官，这些信息有深刻的应用。如果你加入或创建一家价值观与你自己的价值观大相径庭的公司，你会感受到大量的摩擦，让你的生活更艰难。在最高层级，所有这些文化对齐都会在你所做的一切中发挥作用，因为你花那么多时间处于谈判、协作和跨职能团队合作的领域。这并不意味着你不能在一家持有与你不同价值观的公司里取得成功。事实上，你很少能完美同意公司高管团队中每个人的每项价值观。你甚至可能不同意你家里每个人或朋友中每个人的每项价值观！尽管如此，你最看重的特质与你的公司最看重的特质之间的重叠程度，在很大程度上决定了契合对你来说有多容易。

应用核心价值观（Applying Core Values）

无论你是否处于创始或高管职位，理解和培育文化都是你作为领导者工作的关键部分。以下是一些关于如何处理这个问题的建议。

首先，定义你的文化。如果你有一套公司价值观，把这些价值观映射到你的团队上。你可以添加一些对你们团队来说特别的价值观，或者以对你们团队有意义的方式诠释这些价值观。例如，在 Rent the Runway 我的技术团队里，我们明确重视多样性（diversity）。这意味着我们更感兴趣的是你能做什么、你的潜力是什么，而不是让你在筛选过程中符合一整套复选框。我们在公司价值观之上叠加了一层学习文化，因为我们相信这对我们作为工程师很重要。这种叠加的意义在于，每个子团队都会有自己略微独特的文化。有些团队专注于非常专业，在办公室里保持非常规律的上班时间，以非常刻板的方式工作。有些团队偏好更晚或更早的时段，或者不那么正式的会议文化，有更多空间聊天和社交。

其次，通过以积极的方式奖励展现价值观的人来强化你的文化。人们可以在公司全体会议上分享核心价值观故事。在我们技术部门的全体会议上，我们会让人们互相喊话表扬，为「保持酷劲（keeping it dope）」和超越期望的表现喝彩。有些人觉得这种练习很不自在，包括我自己。穿过你身上那部分羞于表扬他人、或不好意思分享感受的自己，走进那部分关心与你共事之人的自己。你可以用不勉强、不虚假的方式分享这些故事。我们作为一个社区讲述的故事，把我们联结在一起。

绩效评估（performance review）最重要的用途之一，是评估团队成员价值观与公司价值观之间的一致性，因此价值观应该成为你绩效评估流程的一部分。指出人们何时、以何种方式展现了团队的一些核心价值观。这种做法以积极的方式强化了期望的行为。它也让你了解团队中谁展现了大部分或全部价值观，谁没有。

学会识别与公司或团队存在价值观冲突的人。如果你的公司有一条价值观是「卷起袖子参与进来」，那么那个不断把工作推给别人的人并没有真正遵循公司的这条价值观。如果你有一条价值观是「幸福和积极是一种选择」，那么那个对每个想法都嗤之以鼻、批评一切的人，融入起来会有问题。有时，人们会改变以采纳这些价值观。「幸福和积极是一种选择」实际上是 Rent the Runway 的核心价值观之一，我不能说我的工作背景是幸福导向的。事实上，我来自一种相当专业且挑剔的工作文化。但我学会了欣赏以积极眼光看待事物的价值。这并不意味着我失去了批判的眼光，而且它从来都不是我最容易完全采纳的价值观，但它不是一票否决的问题。在他们不一致的领域，用核心价值观来指导人们，可以帮助你表达出那些否则可能感觉只是模糊摩擦的东西。

最后，把这作为面试流程的一部分。提醒你的面试官团队的价值观，并要求他们明确留意面试者似乎在哪些地方与这些价值观契合或冲突。很多面试试图通过我称之为「友谊（friendship）」标志的东西来确定文化契合，比如「你愿意和这个人一起被困在机场吗？」你当然不想雇佣你的团队无法忍受与之相处的人，但文化契合不是雇佣朋友。我和一些我不愿意在工作之外聊几个小时的人有过很棒的工作关系，也和一些我愿意一起被困在机场的人有过糟糕的工作关系。此外，由友谊测试决定的文化契合几乎可以肯定在某种程度上带有歧视性。人类与有显著共同背景经历的人交朋友，而这些经历往往与教育背景、种族、阶级和性别等因素高度相关。通过雇佣朋友获得的捷径，通常不是组建强大团队所需的价值观。

所以，在讨论契合时不要含糊。要具体。这个团队的价值观是什么？你注意到哪里匹配或不匹配？一个非常聪明、非常看重独立性的工程师，可能不适合一个所有人都必须在所有项目上广泛协作的团队。一个认为最有分析性的论点总是获胜的人，可能在一家重视同理心和直觉胜过纯粹分析技能的公司里做不好。我用这些例子，是因为这里所有的价值观在某些情况下是兼容的，在其他情况下则不兼容，而这正是使它成为一种有力衡量标准的原因。理解你公司的价值观是什么，理解你团队的价值观是什么，并思考你个人看重什么。如果价值观还没有写下来，就把它们写下来，并尽量明确。用这份明确的清单来评估候选人、表扬团队成员，并为你的绩效评估流程提供信息。

制定文化政策（Creating Cultural Policy）

制定文化政策文件可能很难，因为从零开始起草这些文件很难。幸运的是，你需要从零开始创建的文件越来越少，因为有越来越多的人公开分享他们从职业路径到薪酬等级到事件管理（incident management）等各方面的政策和流程。然而，仅仅有一个起点并复制它，并不总是足够的。我在尝试推出我的第一个工程职业阶梯时，就艰难地学到了这一点。正如我在本章前面所说，添加结构的时机总会到来，而这个时机通常是在事情失败的时候。促使我创建职业阶梯的失败，发生在我们的人力资源团队为工程团队做薪资审查（salary review）时。我意识到我们根本没有薪资结构。由于缺乏结构，大多数人的薪酬是结合了他们之前工作的薪水和他们的谈判技巧决定的。此外，我们很难弄清楚我们需要招聘什么样的人。我们只招聘「高级（senior）」工程师吗？那意味着什么？管理或其他职位呢？

在我们人力资源团队的推动下，我开始创建一个阶梯，我在整本书的多个部分都引用过它。我通过询问我在其他创业公司经营的朋友是否有阶梯来做到这一点。我的一个朋友有，他分享给了我。它有八个层级，从入门级工程师到高管，分为四个类别：技术技能、把事情做完、影响力，以及沟通和领导力。我拿了这个阶梯，添加了一些更多细节，重新命名了层级，然后推出了它。这个临时凑合的阶梯非常基础。对于每个层级、每项技能，你只得到一两句话来说明什么让一个人算是在那个层级工作。即使加上我的一些补充信息，每个类别大概只有四个点可以看。最糟糕的是最早的那些层级，它们是最基础的，给职业生涯早期的工程师提供的指导非常少。我把新阶梯交付给了我的团队，甚至用我朋友向他团队传达它的同样风格传达了新阶梯。我告诉他们，阶梯的存在是为了确保我们在薪酬等事情上公平，而且它是他们可以用来与经理讨论自己的层级、学习如何成长的东西。我告诉人们这没什么大不了的，他们不应该痴迷于自己的层级。然后我花了一些时间谈论约翰·奥斯帕（John Allspaw）的博客文章《论成为一名高级工程师》（On Being a Senior Engineer），试图激励团队推动自己前进。

长话短说，我的第一个阶梯是个失败。

为什么一个在我朋友那里似乎运行良好的阶梯，在我这里却失败得这么惨？我只能推测，但我们的公司之间有一些相当大的差异。我的公司在背景方面非常多元化。我的团队大多来自小公司和创业公司，有少数像我这样在大金融公司工作过的人，只有几个人主要在大科技公司工作过。由于这些多样的工作经历，我们没有任何真正共享的文化习惯可以借鉴。而我的朋友，管理的团队有一个非常大、非常强大的核心，他们都曾在同一家大型科技公司工作过，所以有很多共享的理解，不需要被如此明确地表达出来。

我分享这个故事有一个非常重要的原因：我朋友能够成功的地方，我却失败了，尽管遵循的是同一个模板。这个教训对任何想创造良好团队文化的人来说都至关重要。对一家公司有效的东西——一家正在创造某种类型产品或从事某个行业的公司——并不总能很好地转化到另一家公司，即使这些公司有很多共同点。我们推出各自阶梯时都在管理创业公司，我们的团队规模相似，但我们的团队要成功需要非常不同的东西。我的第一个阶梯是失败，因为我的团队需要更多细节。轻量级阶梯的目标是让团队不要痴迷于他们的层级和晋升，但相反，细节的缺乏导致他们中许多人更加痴迷。工程师们争辩说他们应该处于更高的层级，因为细节很模糊。它导致了一系列没完没了的头疼。

撰写职业阶梯（Writing a Career Ladder）

以下是为你的组织撰写职业阶梯时需要考虑的一些重要问题：

征求团队参与（Solicit participation from your team）。 为了写出更好的阶梯，我不得不改变我的方法。首先，我不再自己一个人做，而是争取团队里高级经理和工程师的支持，让他们提供反馈和细节。我请人们标出他们不理解的地方。我请他们提出重写、补充、编辑和细节的建议。我们作为一个群体讨论它，并且让子群体去处理阶梯中他们最关心的部分。例如，最资深的技术人员（individual contributor）负责技术以及个人贡献者层级技能期望的部分。
寻找范例（Look for examples）。 其次，我从其他公司的朋友那里得到了更多阶梯的范例，以帮助为细节提供一些想法。现在有很多好的现成成果可供你在需要写东西时使用，但在当时，我不得不通过请人们打印出任何他们觉得可以分享的东西、或者给我高层级的笔记来做研究。最好的细节来自较大雇主的朋友，尤其是那些技术声誉很强的公司。解释在非常高级的技术层级上期望的工作范围可能很难，而那些来自大公司的范例确实帮助我们把细节写了下来。
要详细（Be detailed）。 写一个好的阶梯时你会面临的最大挑战之一，是勾勒出细节。你想要一些鼓舞人心且有描述性、但又符合你公司的东西。期望创业公司一个 50 人工程团队的总监管理比如说整个事业部，是没有意义的，而在大型跨国公司里有这种期望则可能合理。想想你在决定某人是否应该被以某个层级招聘进来或晋升到某个层级时，会寻找什么样的细节，并试着把这些细节恰当地包含进去。
同时使用长篇描述和摘要（Use both long-form descriptions and summaries）。 我把阶梯拆成了两份文档。第一份是速记式的电子表格版本，让我能并排看到各个层级的属性，以及它们如何随着层级的升高而演变。这很有帮助，因为写作时我可以看到我是如何从一个层级构建到下一个层级的，以及角色如何在其范围、技能和责任上扩展。第二份文档是长篇版本。写长篇版本对我很有帮助，因为我觉得我可以为每个层级的人讲述一个更完整的故事。长篇阶梯读起来有点像对一个在每个层级表现出色的人的绩效评估，而不只是把层级想象成一组技能和属性。你——以及你的员工——可以看到这些技能如何协同作用，形成一个完整的角色。你的阶梯应该有多少个层级？你需要再回答两个问题才能弄清楚。第一，你如何支付人们薪酬？第二，你如何认可成就？
考虑阶梯与薪资的关系（Consider how the ladder relates to salary）。 你的人力资源部门会想用职业阶梯来帮助设定薪资期望。通常，每个层级会有一个工资带（salary band），即该层级的人可以赚取的最低和最高基本工资之间的范围。如果你的层级不多，你就需要非常宽的工资带，以考虑到该层级内两个人表现可能差异很大，并考虑到工程师往往期望频繁加薪，尤其是在职业生涯早期。
提供许多早期的晋升机会（Provide many early opportunities for advancement）。 有些人建议在阶梯的开始部分设置很多层级，以考虑到职业生涯早期的工程师期望频繁加薪和晋升。你可能希望在一个人职业生涯的头两到三年里每年都能晋升她。如果是这样，创建几个涵盖软件工程师（software engineer）角色的层级，并为这些层级提供相对较窄的工资带，预期是这些角色中的人要么被快速晋升，要么离开你的公司。
对职业生涯早期阶段使用窄工资带（Use narrow salary bands for early-career stages）。 多层级和窄工资带意味着你可以快速晋升人们，并证明给他们加薪是合理的，同时让你在所有处于某个层级的人的薪酬保持相近。如果你担心公平支付、避免可能导致比如说同层级男员工比女员工赚得多的偏见，这是好的。不幸的是，要在相近的层级之间创造出足够的细节，让人能轻松区分某人处于一个层级还是另一个层级，是极其困难的。
在层级较少的地方使用宽工资带（Use wide salary bands when and where you have fewer levels）。 宽工资带和少层级使每个层级的技能之间有更清晰的区分，也应该更容易判断谁在哪个层级运作。在层级间隔较大的情况下，你希望有大的工资带，并且你希望这些工资带相互重叠。所以，软件工程师的工资带可能是 5 万到 10 万美元，而高级软件工程师的工资带可能是 8 万到 15 万美元。这意味着一个很强的软件工程师可能比一个高级工程师赚得多。你需要这个回旋空间来留住那些在当前层级表现出色、但还没有准备好承担下一层级额外责任的人才。你也会发现自己用这个回旋空间，把犹豫不决的人以较低层级招聘进来，期望他们会被快速晋升。
考虑你的分水岭层级（Consider your breakpoint levels）。 公司通常会有某些被视为「向上或出局（up or out）」的层级。这些是职业生涯早期的角色，缺乏晋升意味着这个人没有达到留在公司所需的成熟度或独立性。这种政策往往会作为隐式或显式的分水岭层级转化到你的阶梯中。人们可以永远待着、永远不会被晋升但也不会表现不佳的最低层级是什么？这就是你的分水岭层级。对许多公司来说，它大致在高级工程师附近。走到这一步的人是可靠的团队成员，但他可能会按照自己的选择无限期地留在这个层级。对它的位置有一个概念是好的。你甚至可能想把它用作你的阶梯层级变得更难达到的节点。期待你的团队聚集在这个层级附近，高于或低于它的人更少。
认可成就（Recognize achievement）。 有些公司想保持层级秘密，但这往往是不可能的。人们会谈论。然而，你可以特意强调某些层级，同时让其他层级保持秘密，甚至可能对员工本人保密。有些人力资源部门有独立的薪酬等级编号用来追踪员工薪酬，与职业阶梯完全脱钩。我不是在提倡这个。然而，我确实鼓励你让至少一部分层级成为关键晋升（keystone promotions），即被分享和庆祝的晋升。我认为晋升到高级工程师是件大事，晋升到职员工程师（staff engineer）也是，如果你有这样的角色，首席工程师（principal engineer）也是。在管理轨道上，晋升到总监值得庆祝，晋升到副总裁（VP）也一样。让关键层级之间的距离不太近，能给人们一个超越下一次加薪的更大成就去追求，并让这些层级从更大的职业角度感觉重要。
拆分管理和技术轨道（Split management and technical tracks）。 在当今时代很明显，你需要为管理和个人贡献设置单独的轨道。你不想让人们觉得唯一的晋升路径是管理人，因为不是每个人都适合那个角色。通常，你会看到在高级工程师之上出现拆分，组织开始指定管理层级和技术层级。然而，你不一定应该期望高级技术层级的人数与高级管理层级的人数相同。高级管理通常是一个数量驱动的需求。你需要足够的经理来管理你团队中的人。高级技术取决于你的团队和产品所需的技术领导力的复杂性和范围。可能有一个大团队只有少数高级技术人员，或者一个小团队有许多高级技术人员和更少的经理。在这里达到完美平衡会很不寻常。
考虑让人员管理技能成为职业生涯中期的要求（Consider making people management skills a mid-career requirement）。 鼓励每个人在符合资格晋升到轨道拆分点之上的层级之前，拥有某种管理或指导经验。对大多数公司来说，轨道应该在人们开始展现领导力时拆分，无论这种领导力涉及管理人类还是设计软件。但即使在设计软件时，你也在与其他人和其他人类需求打交道。优秀的高级个人贡献者仍然知道如何管理项目和指导团队中更资浅的成员，所以考虑让领导经验（通常通过担任技术负责人（tech lead）获得）成为晋升到高级个人贡献者层级的要求。
经验年限（Years of experience）。 没有人喜欢给人设置人为的障碍，而经验年限可能感觉是最人为的障碍。话虽如此，我鼓励你在这个问题上明智一点。在我的阶梯中，我通过期望成熟度的增长来区分关键层级，而这些往往与行业经验年限相对应，在较小程度上也与年龄相对应。例如，以职员工程师的情况为例。想清楚大型项目需要大量的个人成熟度，在我看来，这是职员工程师的显著特征。做一个出色的程序员不足以成为一个伟大的职员工程师；你需要展示出完成并支持一些长期工作的过往记录，才能证明这个头衔的合理性。你不必把经验年限作为层级的严格要求，但考虑有一些经验法则，尤其是当你第一次写阶梯并推出层级时。
不要害怕随时间演变（Don’t be afraid to evolve over time）。 当你写这样的阶梯时，你是在创造一个活的文档（living document），它需要随着公司的成长而演变。你可能会漏掉一些细节。我的阶梯对前端（frontend）开发者来说很难解读，因为我自己的重点是基础设施开发，所以我们需要调整它，以更好地说明在那个世界里成为高级表现者意味着什么。

一个好的阶梯是招聘、撰写绩效评估，当然还有晋升过程中的关键要素。如果你有机会创建这样的文档，不要害怕让你的团队参与进来。最好的流程和文档反映的是整个团队，而不只是你当下的偏见，而在小公司里建立这些阶梯最棒的事情之一，就是你可以在没有大量官僚主义的情况下让很多人参与这个过程。

跨职能团队（Cross-Functional Teams）

你和谁一起工作？你向谁汇报？你和谁协作？在极小的公司（答案：所有人）和极大的公司（答案：在你加入之前就已经建立了一个相当清晰的结构）里，答案都是显而易见的。作为一家成长中公司的领导者，你需要至少一次、很可能多次帮助你的团队和公司回答这些问题。答案应该是什么？

我想花些时间谈谈我在 Rent the Runway 工作中经历的最好的事情之一：我们产品工程组织（product engineering organization）的演变。我加入时，工程团队大致分为两组：店面（storefront）组，负责面向客户的网站的所有开发；以及仓库（warehouse）组，支持运行仓库运营的软件。我们很快把店面组演变成前端（frontend）和后端（backend），因为我们正在把代码从 PHP 单体（monolith）重写为基于 Java 和 Ruby 的微服务（microservices）架构。

在我第一年快结束时，我们做了一项实验。我们有一个想为客户构建的新产品，一个基于客户照片评论的功能。因为找到一条合身的连衣裙对我们的客户来说是个挑战，我们想让购物者能看到其他客户上传的、她们穿着这些连衣裙的照片，以及客户提供的关于她们平时尺码、身高、体重和「体型」（运动型、梨形、丰满等）的信息。为了实现这个功能，我们创建了一个跨职能团队（cross-functional team）。我们有专精前端用户体验开发的工程师，也有做后端服务的工程师。我们有一个产品经理、设计师、数据分析师，甚至还有一个来自客服团队的代表。这个跨职能团队作为一个群体协作，设计并向我们的客户交付了这个功能。

这个项目取得了巨大的成功。我们相当快地交付了一个好功能，贡献者们都觉得他们理解了项目的目标，并且因为这个跨职能团队而能更好地工作。在这个项目之前，我们一直深陷「我们对抗他们（us versus them）」的模式，你所在的特定业务职能是「我们」（技术、产品、分析、市场等），组织的其余部分则是「他们」。创建这些协作单元给了人们一个机会，把整个群体视为「我们」。在组织健康方面这是一个明确的胜利，所以我们把整个组织演变成让所有产品工程都由这样的跨职能团队完成。随你怎么称呼它们——「小分队（pods）」、「小队（squads）」或「支柱（pillars）」——但跨职能产品开发团队是一种流行结构，这是有充分理由的。通过把所有让项目成功所需的人放在一个群体里，你帮助这些团队的成员专注于手头的项目，你让整个群体的沟通变得更加有效。

康威定律（Conway’s Law）在讨论这类结构时经常被引用。它说：「设计系统的组织……注定产生出这些组织沟通结构的复制品的设计。」

当我们组建跨职能团队时，我们是在承认最重要的沟通——我们需要优先于一切的沟通——是那种能带来有效产品开发和迭代的沟通。注意，这种结构不一定能产生最有效的技术！事实上，与拥有更以工程为中心的团队结构的公司相比，它可能会产生一些效率低下的系统。所以，你是否应该采用这种结构，你必须决定你愿意在哪些地方承受一些系统设计上的损失，以便最有效地创造产品。

组建跨职能团队（Structuring Cross-Functional Teams）

这种「小分队」结构的细节是如何运作的？一个经常引起焦虑的元素是谁管理谁。当我们转向这种团队组织时，我们没有改变管理结构。工程师由工程经理管理，向我汇报。产品经理向产品负责人汇报。但决定谁在做什么，主要由小分队自己完成。这意味着你仍然可以从你的工程经理那里获得技术指导和监督，但你日常的工作由小分队路线图（roadmap）的需求决定。

当然，每个职能都有自己聚焦的需求。通常工程部门里需要有人监督关键核心系统，而且你可能需要一些专家来处理核心网络平台、移动或数据工程之类的事情。我把这些职能保留在一个小型基础设施组织里，它一般不分配到产品开发中。即使有一个专门的基础设施团队，分配到产品小分队的工程师仍然需要一些时间来处理工程特有的任务，比如值班（on-call）、面试和维持性工程（sustaining engineering），也就是技术债（technical debt）。我建议把所有工程时间的 20% 保留给这类工作，这纯粹基于我个人的经验以及我在工程管理领域的同行们的经验。

这种跨职能结构并非小创业公司独有。许多大公司也以这种方式组织团队。例如，银行通常有依附于业务特定领域的技术团队，虽然管理结构由工程师构成，但路线图和日常工作由业务单元及其相关工程团队的需求共同决定。通常有一个集中的基础设施团队，既支持基础系统，也支持全公司许多团队将使用的大型框架和技术。甚至许多科技公司也是以这种方式组织的，尽管那些「业务单元」本身可能由前工程师领导，他们扮演产品经理或业务经理，而不是业务专家。

跨职能结构的含义是微妙的。这些团队中每个人的价值观都会开始改变。在以技术为中心的结构中，工程师只与其他工程师一起工作，尤其是与他们「同类」的工程师（移动、后端、中间件等），焦点是某种工程卓越衡量标准下的最佳工程师。设计复杂系统或了解最新 iOS 细节的人，是团队的领导者和榜样。在以产品为中心的结构中，领导力的焦点改变了。现在，产品嗅觉最好的工程师、能够快速高效完成功能的工程师、以及与其他职能沟通最好的工程师，开始浮现为团队的领导者。

我在这里不做价值判断，但我鼓励你意识到产品/业务焦点与技术焦点之间的区别，并在有意义的地方应用它。什么对你公司或组织的成功真正重要？如果最重要的事情是演变成一个由许多不同业务领域汇聚而成的产品，你可能需要拥有那种业务嗅觉的领导者。另一方面，在技术必须坚如磐石、或者必须格外创新和前沿的领域，你可能想要更有工程焦点的团队，并由能设计复杂系统的人领导。你不必完全走一条路或另一条路，但要认识到其中之一将领导整个公司，而且——尤其是如果你的角色在高级管理层——把你的技能组合集中在公司本身最看重的那个上，并为另一个方向招聘人才。

发展工程流程（Developing Engineering Processes）

这些年来，我不得不处理许多不同的工程流程。我记得第一次在一个有单元测试（unit tests）、并且要求我们在提交代码前运行的代码库里工作。我非常勤勉地做这件事，而且每次有人因为她没有费心确保她的改动不会破坏测试而搞坏构建（build）时，我都非常生气。我也记得第一次有一个我讨厌的工程流程被强加给我。在多年没有强制代码评审、没有工单（ticketing）、没有追踪之后，一个中央官僚机构决定每个人都必须同时采纳所有这些措施，以推行标准化的软件开发生命周期（software development lifecycle）管理。它感觉没有必要、缓慢、繁重，而且没有人费心向我们解释这些变化为什么会发生。

工程流程是结构问题上真刀真枪见真章的地方。职业阶梯、价值观、团队结构——与为你的团队采用错误的工程流程可能引发的普遍焦虑和挫败感相比，所有这些都算容易的。没有任何流程，你的团队将难以扩展。有了错误的流程，他们会被拖慢。在你团队当前的规模和风险承受能力与手头的流程之间取得平衡，是引导良好的软件开发与运营准则的精髓。

问问 CTO：工程流程

我是一家规模虽小但快速成长的创业公司的工程负责人。我们目前几乎没有流程：没有代码评审，我们用 Trello 管理任务，但很少把所有东西都放进那个系统，我们的架构决策往往由当时正在做项目的人做出，再由我签字批准。

最近，一些工程师来向我抱怨，说新人正在往系统里提交糟糕的代码。他们希望我们为所有改动引入代码评审。我还刚刚发现，有人一直在用 Scala 写一个新系统，尽管我们其余所有代码都是 Ruby 的。他是团队里唯一懂 Scala 的人，我担心支持负担，但项目已经相当深入了，所以我不能直接砍掉它。

我该怎么办？我对于一下子从零流程变成一堆流程感到紧张，但有些事情必须改变！

把流程视为风险管理（risk management）。

随着你的团队和系统成长，任何一个人几乎都不可能把系统都装在自己脑子里。因为我们有一群人在协调工作，我们围绕这种工作协调发展出流程，以使风险变得显而易见。

思考工程流程的一种方式，是它们充当了一件事需要有多难或多罕见才能发生的代理（proxy）。一个复杂的流程应该只存在于你预期罕见的活动，或风险对人们来说并不明显的活动。「复杂」在这种情况下不仅仅指流程长。有时，复杂性在于获得一群非常忙碌的人的签字批准，或者在于达到一个非常高的标准。

这有两个重要的含义。第一个是，你不应该把复杂流程放在任何你希望人们快速行动、并且你相信该活动变化风险很低或风险本身对整个团队显而易见的活动上。如果你想对所有改动做代码评审，确保代码评审的流程没有那么繁重，以至于团队在小的改动上显著变慢，因为那会影响你整个群体的生产力。

第二个含义是，你需要留意有隐藏风险的地方，并把那些隐藏风险暴露出来。政治上有句谚语：「一个好的政治想法是那种以半成品形式就能运作良好的想法」，工程流程也是如此。即使流程没有被完美遵守，它们也应该有价值，而这个价值应该主要在于把变化或风险社会化给整个团队这个行为本身。

实用建议：让决策去人格化（Practical Advice: Depersonalize Decision Making）

随着团队成长，你应该考虑添加三个主要流程。当你围绕这些流程设定行为期望、而不仅仅是技术细节时，所有这些流程都运作得最好。

代码评审（Code Review）

代码评审，无论好坏，都是现代标准。一旦你有了一个规模够大、有一定数量的人在代码库上工作的团队，代码评审就可以成为确保该代码库稳定性和长期质量的有价值工具。然而，强制代码评审也会成为完成工作的关键路径（critical path）上的一环，所以你希望流程直接而高效。此外，代码评审常常是工程师彼此行为恶劣的地方，把它当作批评同事或强制执行不现实标准的平台。以下是一些让道路更顺畅的最佳实践：

明确代码评审的期望（Be clear about code review expectations）。 在大多数情况下，代码评审抓不到 bug；测试抓 bug。这条规则的例外是，代码评审可以抓到对注释或文档的缺失更新、或对相关功能的缺失改动，而且代码评审者有时能判断出新代码或改动代码的测试是否不足。代码评审在很大程度上是一种社会化练习，让多个团队成员看到并了解被改动的代码。
对风格问题使用 lint 工具（Use a linter for style issues）。 工程师可以在风格问题上浪费荒谬的时间，尤其是格式问题。这不应该成为代码评审中争论的内容。决定一种风格，把那种风格放进一个自动格式化代码的 lint 工具（linter）里。让风格成为代码评审中讨论的话题，往往会导致吹毛求疵和批评，好一点说感觉毫无成效，坏一点说感觉像霸凌。
留意评审积压（Keep an eye on the review backlog）。 有些公司对一个人可以被分配多少个未完成的评审请求实施限制，当一个人有太多未完成的请求时，就阻止他再请求评审。想想你希望如何让这些请求在系统中被推动前进，以及你如何确保每个人都在他们的代码上得到充足的时间。

故障事后复盘（The Outage Postmortem）

我不打算谈事件管理的细节，但「事后复盘（postmortem）」流程是良好工程的关键要素。事实上，许多人不再把这个流程称为事后复盘，而是开始称之为「学习回顾（learning review）」，以表明它的目的不是确定死因，而是从事件中学习。关于这个话题已经写了很多，所以我只强调我认为关键的一些要素，尤其是对小团队而言：

抵制指手画脚和责备的冲动（Resist the urge to point fingers and blame）。 在一次压力巨大的故障之后，指着别人问他们为什么没能预见到自己行为的后果，是极其诱人的。他们为什么在那台机器上运行那个命令？他们为什么没有测试那个？他们为什么忽略那个警报？不幸的是，这种责备只会导致人们害怕犯错。
审视事件周围的情况，理解事件的背景（Look at the circumstances around the incident and understand the context of the events）。 你想理解并识别促成这次事件的因素。这可能包括寻找本可以检测到问题的测试，或本可以让事件管理进行得更顺利的工具。把这些情境性促成因素列一个好清单，能帮助你发现模式或需要改进的领域，并构成学习回顾的「学习」部分。
对哪些心得重要、哪些值得放弃要现实一点（Be realistic about which takeaways are important and which are worth dropping）。 小心不要给人留下这样的印象：人们需要解决他们在练习过程中发现的每一个问题。许多学习回顾以一张长长的、可以改进事项的清单结束——从清理警报，到添加角色限制，到跟进第三方供应商以理解其 API。你不太可能全部做到，而且事实上，如果你试图全部做到，很可能最终一个都做不成。选择真正高风险、极有可能导致未来问题的一两个，并承认那些你现在打算放过的。

架构评审（Architecture Review）

我要把团队可能希望做出的所有重大系统和工具变更都归入架构评审（architecture review）。架构评审的目标是帮助把大变更社会化给合适的群体，并让这些变更的风险变得清晰。你可能要求人们准备好回答的一些问题包括：

团队里有多少人乐于使用这个新系统/写这门新语言？
我们为这个新东西建立了生产标准吗？
推出这个东西并培训人们使用它的流程是什么？
使用这个东西有没有新的运维（operational）考量？

以下是一些指导原则：

具体说明需要架构评审的变更类型（Be specific about the kinds of changes that need architecture review）。 通常这些包括新语言、新框架、新存储系统和新开发者工具。人们常常想用架构评审来防止团队糟糕地设计新功能，但在小公司里试图尽早抓住新功能设计通常是不现实的，在大公司里也很难。它还会大大拖慢速度，而且如我们之前的观点所说，你可能不想在功能设计这样的常见活动前面放一个沉重的流程。
架构评审的价值在于为评审做准备（The value of architecture review is in preparing for the review）。 要求对系统的重大变更或新增进行评审，迫使人们思考他们为什么想做出这些变更。再说一次，这些流程的一个价值是帮助人们意识到他们可能没有考虑过的风险。你可以选择让团队回答为什么要做这个变更的问题，也可以不选。我发现当人们愿意并且能够通过做出变更所需的要求时，为什么是显而易见的。
明智地选择评审委员会（Choose the review board wisely）。 你希望评审委员会包含受变更影响最大的人，而不只是一个静态选定的专家团。目标的一部分是让自己摆脱为每个技术决策坐热椅的处境，目标的一部分是确保那些需要处理决策结果的人参与评估它。你希望这些决策考虑到更广泛的团队，并让更广泛的团队认同它们。这没有理由需要是全公司范围的。决策群体的范围最好保持在会密切受到该决策影响的人。没有什么比让一个来自完全不相关领域的人否决一个项目更令人士气低落的了。

评估你自己的经验（Assessing Your Own Experience）

你现在有什么政策？什么实践？你写过其中任何一条吗？你上一次重新审视它们是什么时候？
你有公司价值观吗？它们是什么？你如何在你的团队中认可它们？
你有职业阶梯吗？你觉得它准确地反映了今天的团队吗？它反映了你未来想要的团队吗？如果没有，你能改进它吗？
哪些风险最令你的团队担忧？你的公司呢？你如何在不给团队增加不必要的流程和官僚主义负担的情况下减轻这些风险？

1 约翰·高尔（John Gall），《系统学：系统如何真正运作，尤其是它们如何失败》（Systemantics: How Systems Really Work and Especially How They Fail）（纽约：Quadrangle/The New York Times Book Co, 1975）。

原书插图