平等工程

工程师设计产品时，需要注意拥抱多样性、设计适合所有人的系统。这是一个崇高的目标，因为在成为高绩效工程师 道路上充斥着大量的利己主义思想。但是尽管这反映出重大的系统性挑战，但这是需要解决的一个问题。

解决该问题，既意味着尝试挑战既定流程、提出公平性问题，也意味着构建合适的价值观：

• 仔细照镜子：需要有代表性个体或集中的社区反馈参与到产品设计中，作为参照。
• 不是 Build for Everyone 而是 Build with Everyone：需要和社区合作，一起设计产品，而不是闭门造车。
• 为困难用户设计：为那些有额外挑战的人优化产品，提升每个用户的体验，而不是为了短期流量舍弃公平性。
• 在整个系统中衡量公平：决策者也有偏见，不要假设公平，而是需要与在多样性、公平性和包容性方面能提供专业建议的个人或团队合作。
• 改变是最可能的：不能用过去的方法和经验以及陈旧的技能来解决问题，而是要积极寻求改变。

团队领导的艺术与责任

工程经理和技术主管

在 Google，工程经理 (EM) 和技术主管 (Tech Lead, TL) 是两个不同的角色，在新生团队中二者有时可以合并为技术主管经理 (TLM)：

• 工程经理 (EM)：负责团队中每个人的绩效、生产力和幸福感，确保产品满足业务需求。
• 技术主管 (TL)：负责技术决策，确保团队的技术方向正确，并且与公司的整体技术战略一致。随着团队规模增长，其需要尽可能将任务委托给团队成员完成 (虽然速度可能会更慢)。

从个人贡献者到领导者

如果产品需要有所进展，则总需要人站出来把握产品的方向。这类情况常常被描述为“经理人炎症”：

经理人炎症 当一个团队中的个人贡献者 (IC) 从未想过要当领导者，但不管怎样它还是发生了。

在成为领导者后，有非常多的事情需要担心，同时心态上也会发生不少转变。在这个过程中要注意，不要掉入“数苹果陷阱”：当你种香蕉时，不要想着数苹果，即使之前你很擅长种苹果和数苹果。在这个过程中，领导者需要学习如何平衡个人工作、授权和人员管理，也需要培养自己的“非职权领导力”。

仆人式领导

请不要忘记原来的管理者所做过的糟糕事情，包括微观管理、忽视表现不佳的员工、以及聘用平庸的员工。最重要的是要克制住管理的冲动。比较合适的，是充分运用“仆人式领导”，为团队服务，努力营造出一种谦虚信任的氛围，消除团队成员自己无法消除的官僚障碍、帮助团队达成共识，“管理好团队的技术和社交健康”。

工程经理

传统的经理担心如何完成任务，而伟大的经理关心的是要完成什么任务，并相信他们的团队能想出如何完成任务。同时不要对失败产生反感；也不要将失败归咎于个人，因为这回分裂团队且使大家丧失冒险的信心。

反模式

如果想成为一名成功的领导者(包括工程经理和技术主管)，需要防止一些反模式：

• 雇用平庸的人：不要因为担心有人质疑权威或威胁工作的方法，就雇用平庸的人；而是要努力雇用比你更聪明、更可能取代你的人。
• 忽视低绩效员工：员工低绩效情况中最困难的情况是，无论他们工作多久或多努力、都没有能力完成工作。面对低绩效员工，需要保持谦虚、尊重和信任的态度尽快展开沟通，设定一个具体的时间框架、以及希望他们在这段时间内实现的某些非常具体的目标，把这些目标定得小、渐进且可衡量，让员工有机会取得很多小的成功。
• 忽视“人”的问题：请不要忽视“人”的问题，有时候一点点的同理心会让大家都很开心。
• 做老好人：不要做老好人，但是也不要过于严苛；与团队成员共进午餐是一种有效的方式，既能与他们保持社交联系，又不会让他们感觉不舒服，这提供了在正常工作环境之外进行非正式对话的机会。
• 打破招聘门槛：不要为了招聘而打破招聘标准，纳入不符合招聘标准的人，这会导致团队生产力丧失、团队压力、花费更多管理员工时间、解雇员工所需的额外文书工作和压力等等各种问题。
• 向孩子一样对待团队：如果雇用了值得信任的人，并向他们展示自己的信任，他们往往会应付自如。

积极的模式

谈论完反模式后，进一步谈论积极模式：

• 抛弃“自我”意识：应该努力培养强大的团队自我意识和认同感，并在团队内建立信任，领导者可以推动团队达成共识并帮助确定方向，但具体细节最好由生产产品的人决定；同时要保持总揽全局、公开接受反馈和批评，避免山头主义。
• 成为一名“禅师”：在领导团队时，需要保持冷静，并注意激励团队；另外当他人寻求建议时，作为领导不应该直接接手解决，而是应该帮助他们解决问题、通过问他问题的方式让他自己解决问题。
• 成为催化剂：领导团队的过程中，作为领导需要建立共识，让整个团队朝着正确的方向推进。
• 移除障碍：当团队面临技术或组织上的障碍时，作为领导并不需要知道所有解决障碍的答案，反而找到能解决障碍的人往往更重要。
• 成为老师和导师：一个好的导师必须权衡学员的学习时间和他们为产品贡献的时间；在交流时，需要给徒弟足够的信息，但是也不要过度解释或唠叨。
• 设定清晰的目标：领导团队时，需要设定明确的目标和优先级，为团队创建一个更简洁的使命声明，给团队更多自主权。
• 坦诚：请坦诚面对下属，建议不要使用“三明治评价法”，防止关键信息传递丢失；表达上应该确保信息被听到而不被曲解。
• 追踪幸福感：领导者需要花些时间衡量和调节团队的幸福感，比如将困难或麻烦的任务均匀分工给团队内的各成员、组织出游或团建、一对一沟通和小心追问等等。同时也需要给团队成员自我提升的机会，从而让他们在职业生涯中收获到一些乐趣。

做领导者的提示与技巧

要成为一名优秀的领导者，还可以参考下述提示与技巧：

• 委派工作，也要亲自动手：前者是为了提高效率，后者是为了防止目标偏离。
• 寻找替代者：不要在团队中唯我独尊，而是要积极寻找替代者，即“比你更聪明之人”。
• 知道什么时候该做什么：不应该无限制地拖延，防止一些消极事件的负面影响。
• 保护团队远离混乱：需要让团队专注于目标，作为领导要尽可能保护团队不受外部混乱的影响。
• 给团队提供空中掩护：需要让团队了解公司“上面”发生的事，但也要防止团队专注力被这些事情影响。
• 让团队知道他们做的很好：作为领导者可以在适当的时候给团队一些表扬，提升他们的积极性。
• 对容易“回退”的事情说是：需要知道什么时候可以撤销哪些事，鼓励团队尝试新事物。

另外，作为领导者，需要“见人下菜碟”，激励墨守陈规的人、也为飘忽不定的人提供方向；在产品研发方面，培养研发者的主人翁意识和自主权，并提供机会提升他们的现有技能和鼓励学习新技能，同时赋予他们工作的目的。

大规模团队领导力

要成为一个真正优秀的领导者，需要培养“三个总是”的能力：

• 总是在决策 (Always Be Deciding)
• 总是不在场 (Always Be Leaving)
• 总是在拓展 (Always Be Scaling)

总是在决策

作为一个领导者，需要决定团队每周应该做什么，“透过树木见森林”，识别盲点、识别权衡，最后决策并迭代解决方案。尤其是在决策和迭代方案的过程中，需要使用当前信息为当前月做出最佳决策，但在下个月又需要再次重新评估和权衡利弊，从而让团队适应迭代。

“不可能三角” 好、快、省三角中，只能一选二。我们往往需要更好地理解所有的权衡，让我们能开始尝试新的方法。我们不应该将某些问题视作不可避免和偶然的副作用，而是应该将其与其它目标一起视为首要目标，从而构建新的策略。

总是不在场

不要将自己设置为单点故障(SPOF)的一种情况，而是要构建一个有自驱力的团队，通过划分问题空间、授权子问题和根据需要进行迭代这三点实现。

针对第一点，可以考虑构建一个更松散的组织结构，其中的子团队可改变规模；并将子问题进行授权，通过“快速失败，不断迭代”，保证高级战略能得到部署、构建的蓝图能不断推进。相比之下，花大量时间仔细观察和倾听，相比微观管理和尝试不断修正航向更为有效。同时请注意谨慎锚定团队身份，尽可能让团队负责一个一般性问题，而不是特定的产品。

总是在拓展

一个团队处理一个难题时，就会出现一个标准模式，即一种特定循环：

• 分析：接受问题并全力以赴解决。
• 争论：着手工作和形成初步意见，“假装”能制定总体策略。
• 牵引：团队想出办法，并开始真正解决问题。
• 奖励：获得阶段性成果，但承担更多责任。

在整个过程中，整个过程处于螺旋上升的状态，不断得到推进。

在这样一个循环中，作为领导者，需要知道如何迫使自己在重要的事上工作，而不是在紧急的小事上过分浪费时间：

• 授权：需要把一些消失交给其它领导者或下属完成，从而腾出更多时间解决重要的事情。
• 安排专门的时间：定期抽时间专门做重要的事情，从而形成规律性。
• 找到有效的跟踪系统：使用合适的系统进行管理，用于跟踪工作和确定工作优先级。
• 学会放弃：领导者真正要做的往往是识别和处理前20%最有用的任务，并相信其它任务会被妥善处理或得到适当升级。这样会让自身扩展出更多时间和注意力承担团队日益增长的责任。

保护自己的精力

领导者需要学会更好地管理自己的精力，并学会持续关注一件事。下面提供一些进行精力管理的方式：

• 享受真正的假期
• 让切断变得轻而易举
• 享受真正的周末
• 白天小憩
• 给自己一天心理健康假

度量工程生产力

随着业务范围的扩大和组织规模的线性增长，沟通成本呈几何级增长，因此很难根据工程组织的规模按比例线性扩展业务范围。因此自然需要知道，如何提高软件工程的生产力，以及如何高效做到这一点。这就需要对工程生产力进行度量，从而提供更好的优化方案。

确定哪些指标值得度量

在度量生产力前，需要思考一系列问题来帮助团队确认其必要性，以及想度量什么。简单来说就是：人们在被度量对象上的成本投入是否值得为公司带来好处。

具体来说，就是要考虑下面各方面的问题：

• 你期待什么结果，为什么？
• 如果数据支持你的预期结果，你将采取什么行动？
• 如果得到了一个负面结果，是否会采取适当行动？
• 谁将决定对结果采取行动他，他们何时采取行动？

因此当出现下面的状况时，度量生产力的必要性并不大：

• 现在你无力变更流程/工具：需要考虑更广泛的上下文，以推迟对结果度量和产生行动。
• 任何结果不久都会因为其它因素无效：需要综合日志和访谈等多方成果综合考虑是否需要度量生产力，且度量结果是否不会在不久后就失效。
• 结果仅用作虚荣心指标，以支持无论如何都要做的事情：这样度量生产力根本没有意义，因为不会对后续决策和行动造成影响。
• 仅有的度量指标不够精确，不足以度量问题，且会与其它因素混淆：这就造成了度量工作难以很好地进行，从而造成不佳的结果表现，这样结果的参考价值不大，进行生产力度量行为的意义自然也不大了。

因此综合来说，只有当基于度量结果能够做出具体决策时，我们才应该去进行生产力度量。

根据目标和信号来选择有意义的指标

在创建指标时，可以用目标/信号/指标框架(GSM，Goals/Signals/Metrics)指导指标创建：

• 目标：期待达成的最终结果，用于表达想了解的高层次内容，且不应该制定某种具体的度量方法。
• 信号：用来判断是否已经得到了最终结果的东西，也即想要度量的东西，但它们本身可能无法度量。
• 指标：信号的代理，事实上可以度量的东西。

该框架通过鼓励在实际测量结果前，提出适当的度量指标，并制定一些有原则的方法，从而帮助避免指标蔓延和指标偏差。GSM鼓励基于原始目标选择度量指标，从而防止了目标偏移。注意，并不是所有信号都是可被度量的，且重要的是要保证可追溯性。

目标

目标需要按照所期望的特征来撰写，它们本身是不可测量的，但是一套好的目标是每个人在着手于信号和度量前都可以达成一致的。在度量生产力方面，可以将衡量生产力的目标设置为五个组成要素：

• 代码质量 (Quality of the Code)
• 工程师的专注力 (Attention from Engineers)
• 认知复杂度 (Intellectual Complexity)
• 节奏和速度 (Tempo and Velocity)
• 满意度 (Satisfaction)

它们被统称为 “QUANTS”。

信号

信号用来让我们知道是否已经实现了目标，一个目标可以对应多个信号，多个目标也可能共享一个信号。

指标

指标是作为信号的可度量代理而存在的，有的信号可能根本无法测量。指标包括定量指标和定性指标，比如考虑用一种调查机制跟踪工程师信念的纵向指标。同时注意定性指标也应该与定量指标保持一致，如果不一致，则可能定量指标不正确。

在构建一整套工程生产力度量体系并实施后，会得到一些推荐和建议，不过这些推荐建议是“工具驱动”的，而不是仅仅告诉工程师要去改变他们的工作流程或思维方式。这些推荐和建议应该被内置于整个工作流程和激励结构中，从而固化到工作人员的日常习惯中，而不只是进行简单的培训或文档撰写。