管理者手册
有效管理的启发式方法。
目录
这适合谁?
这是我从自身经验和其他管理者那里学到的启发式方法集合。它旨在成为一个不断更新的文档。我尽量保持简洁明了。
这主要是为刚开始管理生涯的人提供建议。对于想要提升技能的有经验管理者也很有用。
什么造就一个优秀的工程经理?
你的首要任务是执行。作为一名管理者,你是一位领导者,利用你团队的技能来实现特定目标。为了实现这一点,你需要成为一个熟练的教练、沟通者和决策者。然而,这些角色只是达到目的的手段。
一个杰出的工程经理通过培养持续改进和创新的文化来提高团队的标准。每周都应该标志着一个新的里程碑,团队在效率、创造力和解决问题方面超越之前的成就。你不仅仅是管理;你以身作则,激发更加专注和深刻的目标感。进步是切实可见和令人振奋的。虽然员工工程师通过技术充当力量倍增器,但你通过人来充当倍增器。
我应该有多技术化?
有效的工程经理应该具备强大的技术背景,亲身经历过他们团队面临的挑战。我建议个人只有在至少达到高级工程师水平,最好有至少10年的技术个人贡献者经验后,才考虑转向管理岗位。经历技术努力的战争创伤是至关重要的。
这样的管理者应该理解项目的技术细节,甚至能够为其做出贡献。他们必须善于做出技术决策并阐明其背后的原因。然而,这并不意味着他们应该积极参与关键路径上的编码或做出所有决策。
如果你有超过7个直接下属*,你通常应该避免在关键路径上编码,以确保你不会在关键功能或事件上阻塞团队。Charity Majors的建议:
- 编写功能? ⛔️
- 当有人需要休息时覆盖值班? ✅
- 事后分析后投入最大的项目? ⛔️
- 代码审查? ✅
- 处理令人烦恼但似乎从未成为最高优先级的P2级bug? ✅
- 坚持所有提交都需要他们批准? ⛔️
- 清理监控检查并编写库以生成覆盖率? ✅
*这个数字可能会根据你的会议负担而变化
一对一会议
永远不要跳过一对一会议。它们是指导和提供反馈的重要机制,也是与团队成员建立联系的方式。大多数工程师都珍惜这些会议,如果他们不珍惜,通常是因为他们没有经历过一次好的一对一会议。
请注意,这些建议主要针对与个人贡献者的一对一会议。与经理的一对一会议通常更倾向于"业务"事务,强调战略、团队健康和项目规划。
一些一般建议:
- 目标是每两周进行30分钟的一对一会议,但根据你的团队成员的喜好调整频率。
- 与你的下属共享一个文档很有帮助,你们双方都可以提前写下议程项目并跟踪行动项目。但知道什么时候不按脚本也很重要。并非所有下属都会重视这一点。
- 我发现每月或每季度通过问这些"1到10的评分"问题进行健康检查很有帮助。通常如果我得到的不是9或10,我会深入了解。"在1-10的评分中,你会如何评价:..."
- 可预测性:你对期望你做什么感到多清晰?
- 所有权:你对决策权和方向的满意度?
- 目的:你的工作对团队产生多大的影响?
- 进展:每周的进步感?
- 归属感:你与团队的联系感?
- 其他有助于激发讨论的问题:
- 你工作中最有趣的部分是什么?
- 在这里工作有什么不有趣的?
- 每周最浪费你时间的事情是什么?
- 你想提高哪些技能?
- 你在寻找什么样的职业道路?
- 公司里你想更多地了解谁?
- 你想更多地参与业务的哪些部分?
- 你不喜欢产品的哪些方面?
- 我们错过的最大机会是什么?
- 你认为本季度你的前3个优先事项是什么?团队的呢?组织的呢?
- 如果你是CEO,你会做什么不同的事?
- 我能做什么来更好地支持你?
- 如果你是我,你会改变哪1到3件事?
- 你对你得到的反馈量感觉如何?
- 我需要反馈。我可以做些什么不同的事?
- 我们可以做什么来改善我们的协作方式?
鼓励你的直接下属提出话题:
更多阅读,请参阅从你的一对一会议中获得更多,了解关于有效一对一会议的更多想法。
高效团队
作为管理者,确保你的团队尽可能高效运作是你的工作。为此,每个高绩效团队都应具备三个关键属性:
- 自主性:团队应以工作流独立于其他团队的方式运作。这使他们能够做出决策,而无需得到团队外部的批准。此外,团队应该能够以最小的开销运作。这通过拥有出色的开发者工具和明确的流程(例如测试、变更管理等)来实现。
- 领域掌握:团队应该是其特定领域的专家。这包括对产品、代码库和业务环境的深入了解。
- 目标:团队需要理解更大的图景,并辨别他们的贡献如何与之契合。这种理解为他们的任务提供了"为什么"的清晰度。此外,无情地优先排序你的项目,确保你的团队不会分散在太多倡议上。这使他们能够专注于最重要的工作。尽可能集中攻关,让每个人都感觉他们在朝着共同目标前进,并且有知识共享。最后,最好的工程师希望受到挑战并从事重要的项目。团队应该解决既重要又紧急的问题。
缺乏这些支柱(归功于Dan Pink),团队可能会变得不那么有效,并可能经历动力减弱。
更多阅读,请查看团队拓扑,它更深入地探讨了团队组织理论。
指导
指导是管理者可以拥有的最重要的技能。这是帮助你的下属成长并对他们的工作负责的最佳方式。
- 默认使用开放式问题:问以什么、如何、谁开头的问题,而不是以是否、有没有、是不是开头的封闭式问题,以邀请对话并赋予问题所有权。
- "你有什么问题?"比"你有任何问题吗?"更好。
- "你为什么认为这是正确的方法?"比"这是个好主意吗?"更好。
- 当被问到"我应该怎么做?"时,回答"到目前为止你有什么想法?"
- 总结对方所说的内容,以确保你们双方都在同一页面上并准确定位问题。
- "听起来有两个问题,x和y。我们应该先关注哪一个?"
- 弄清楚如何使会议富有成效:
- "下一步是什么?"
- "我们应该如何跟踪这个?"
项目管理
没有一种正确的方法来管理项目。这取决于团队的规模、项目的类型和团队的成熟度。以下是一些一般建议:
- 将项目拆分成可在一两周内完成的小块。
- 优先考虑影响最大和最紧急的项目。
- 尽量减少并行化。完成一个项目比两个项目完成一半要好。
- 为每个项目指定一个负责人。此人负责推进项目并沟通进展。让他们创建技术规格并根据截止日期倒推。
关于项目执行的精彩书籍,请查看[大事如何成功]。
给予反馈
给下属/经理/同事提供出色的反馈是促进一致性和建立信任最有影响力的事情之一。
- 及时反馈,最好在引发反馈的事件当天提供。等待太久会显得你在记仇,而且几天后他们可能不记得细节。
- 获得提供反馈的认可,并通过提供背景减少神秘感:
- "你有10分钟时间吗?" ⛔️
- "你有10分钟时间讨论今天早上的站会吗?"
- "我可以和你分享一些关于我们合作方式的想法吗?"
- 不要用赞美来掩饰负面反馈;这会传递混合信号。
- 即使是正面反馈也要具体。
- "干得好!" ⛔️
- "我喜欢你主动减少服务内存占用的做法。这让我更有信心给你更多的所有权,这样我就可以专注于其他方面。"
- 避免仅仅因为完成工作就表扬。你要确保反馈是真诚的,而不仅仅是为了避免给出负面反馈。
- "谢谢你修复了那个bug" ⛔️
- "谢谢你修复了那个bug。这对客户来说很关键,而且你很快就完成了。"
- 关注数据而不是行为:
- "我注意到你没有回应最近三个PR中的任何评论"
- "我注意到你没有完成我要求你做的任务"
- "我注意到你最近发布的功能没有任何测试"
- "你的代码有bug" ⛔️
- "你总是迟到" ⛔️
- 讨论为什么这很重要以及影响到谁:
- "我提到这一点是因为我们作为一个团队工作很重要"
- "我提到这一点是因为我分配给你的任务对本季度的路线图至关重要"
- 一起讨论如何解决问题:
- "你对我们的流程有什么看法?"
- "你是怎么看的?"
- 就行动计划达成一致:
- "我们如何确保下次不会错过任务截止日期?"
- "你现在可以采取哪些行动?"
- "我们的行动项目是什么?"
- 突出积极模式(记住要具体)。
- "看到你教X关于Y的知识让他们和你一样熟练真是太好了。这是高级工程师的特质。"
- 重复本能反应以帮助框定对话:
- "我对你的提议的初步反应是..."
- "这是我会做的"比"这是你应该做的"要好
- "当你做X时,我感觉Y"
更多阅读,请参阅[反馈的兴起:为什么反馈技能变得迫切]和[想得到更好的反馈?问一个更好的问题。这里是方法]。
战略思考
无论你在组织中处于什么级别,你都应该在团队解决业务问题的背景下进行战略思考。这意味着理解大局,以及你的团队的工作如何融入其中。
你应该问自己的问题:
- 你的团队如何推动进展?你是否专注于正确的事情?
- 你的产品的使命和宗旨是什么?
- 公司今年的首要任务是什么?三年后公司应该处于什么位置?
- 解决这个技术债务是否有助于实现业务目标?
- 你的团队在推动哪些公司年度目标,以及以何种方式?
- 你团队的痛点是什么?如何提高2倍速度?
- 如果公司失败,最可能的原因是什么?
- 如果多一个人,你会做什么?
关于战略的优秀书籍:
- [好战略/坏战略]
- [创新者的解决方案]
- [跨越鸿沟]
决策
- 确定决策是[可逆的还是不可逆的]。
- 可逆决策可以轻易改变。例如:改变站会时间,贡献指南。
- 不可逆决策不能在没有重大返工的情况下改变。这些决策应该花更长时间,并记录和讨论。例如:架构变更,招聘,组织变更,数据模型。
- [Sam Newman]关于技术决策的量表: <图片>
- 当有分歧时,关注决策的预期结果,并确保团队了解你的推理。
- "虽然数据库X更好,但我希望我们标准化使用一个技术栈,以便更容易维护。"
- 如果有人不同意可逆决策,设定一个日期与团队重新审视该决策。理想情况下,你还应该有衡量该决策成功与否的指标。
- "我理解你的担忧。让我们一个月后重新审视这个问题,看看情况如何。"
- "我们现在正在跟踪X,让我们在下个季度重新审视,看看这些变化是否有改善。"
- 如果有人不同意不可逆决策,给他们机会陈述他们的理由。无论如何,每个人都应该知道最终决定权在你,团队需要[不同意但完全承诺]执行所做的决定。根据我的经验,即使持异议者如果觉得被倾听并欣赏你果断做出决定,也会承诺执行决定。
- 记录你的决定,这样你就可以回顾为什么做出这些决定以及团队面临的权衡。
任务和PR流程
- 为团队制定贡献指南。
- 优先处理PR以解除任务阻塞。
- 避免合并腐烂。我建议利用一次站会来审查PR积压,并指出超过2天的PR。
- 使用代码检查或格式化工具自动化样式等意见。
会议
- 通过鼓励在开会前写下提案来避免[糟糕的头脑风暴会议]。想要开会的人应该写提案。
"不要将决策推迟到会议上。当场做出决定,通过长篇书面形式沟通,并利用会议讨论。" - Erik Bernhardsson
- 对于提案,倾向于长篇书面形式而非演示。写作迫使作者思考细节和权衡。我发现创建技术规格模板非常有帮助。
- 在会议期间留出时间阅读和讨论提案。这确保每个人都在同一页面上,并避免"我没时间阅读"的借口。它还将确保这是每个人记忆缓冲区中最新的内容。
- 避免没有议程的定期会议。如果你被邀请参加这样的会议,请询问议程。
- 鼓励亚马逊风格的["6页纸"和"2页纸"]。
- 总是以行动、负责人和时间表结束会议,以明确下一步骤。
<图片>
招聘
如果你能"严格招聘",你就能"轻松管理" - Sue Tetzlaff,《员工体验》
招聘是经理做出的最重要决定。这也是最困难的。这是一项可以学习和改进的技能。
在工程师中寻找什么:
-
主人翁意识。即使问题不是100%自己的责任也会承担起来;理解背后的原因。
- "请告诉我一次你承担了超出自己职责范围的重要任务。为什么这很重要?结果如何?"
- "请讲述一次你做出了艰难决定,牺牲了短期利益以换取长期目标。"
- "你做过的一个重大权衡是什么,你是如何做出这个决定的?"
-
处理模糊情况
- "你能告诉我一次你必须解决一个雄心勃勃的问题的经历吗?为什么这个问题很重要?"
- "你能告诉我一次你在信息不完整的情况下必须做出决定的经历吗?情况是怎样的?你承担了什么风险?你为什么做出这样的决定?"
-
团队合作者。能很好地接受反馈。
- "告诉我一次你改变主意的经历。你的思考过程是怎样的?"
- "告诉我一次你与经理意见不合的经历。你从这种情况中学到了什么?"
- "告诉我一次你需要一个不配合的同事合作的经历。你做了什么?结果如何?"
- "给我一个你收到的严厉或关键反馈的例子。是什么反馈,你做了什么?"
- "如果我问你的同事,他们会对你有什么积极或消极的评价?"
-
沟通者。能在不同层面清晰表达想法。
- "什么造就了一个优秀的工程师?"
- "向我描述一件你非常了解的事情。"
- "你在简历中提到了X。假设我从未接触过它,请向我解释一下。"
-
教师。乐于培养其他工程师。对高级工程师尤其重要。
- "告诉我一次你帮助团队中某人成长的经历。"
-
深入探究者。深入挖掘以了解底层原理。
- "告诉我一次你试图理解团队中的问题,不得不深入多个层面才弄清楚的经历。"
- "如果你有两周时间专心学习新东西,你最想学什么?"
-
简化者。简化问题而不是仅仅修补和增加技术债务。这个人是否有构建vs购买的心态。
- "告诉我一个你用简单解决方案解决的复杂问题。"
-
使命感。对公司的使命或技术感兴趣。
- "向我解释你当前公司做什么,为什么它很重要。"
- "在[公司名]工作对你有什么吸引力?"
需要注意的问题:
- 在公司任职时间短。如果候选人通常在公司工作不到一年,询问原因。可能有完全合理的理由,也可能表明这个人难以共事。
- 为什么你在X公司只工作了不到1年?
- 技术清单。简历中只列出使用的技术而不是解决的问题,可能表明此人没有考虑大局。这也是初级工程师的典型特征。
- 缺乏好奇心。此人是否询问有关公司、产品或团队的问题?
- 没有职业发展。此人是否有清晰的职业发展轨迹?如果没有,为什么?
- 角色描述。这个人只是在描述他们的工作,还是在分享他们在公司产生的实际影响?
- 缺乏可量化的指标。这个人是否有指标来展示他们工作的影响?
关于候选人你应该问自己的问题:
- **他们是否比团队中的平均水平更好?**如果不是,你就没有提高标准。
- **你是否钦佩这个人并想向他们学习?**如果不是,你就没有雇用比你更优秀的人。
推荐人
你应该抓住机会进行推荐人电话。它们可以告诉你很多关于候选人的信息。这里有一些技巧:https://gist.github.com/ksindi/bbade71640bb62c4547348c3bb355739。
入职
有一个好的入职流程对你的团队的成功至关重要。它确保新成员尽早做出贡献,并融入你的流程和文化。
如果你的新团队成员在加入的第一天就能贡献一个bug修复,那么入职流程就是成功的。
入职材料:
- 团队使命
- 你的团队如何为客户推动进展?
- 团队成员
- 包括:姓名、角色/职位、电子邮件、Slack用户名、GitHub用户名
- 代码库和服务
- 包括系统图
- 团队内如何沟通
- Slack频道
- 如何保持信息更新
- 工作时间内外的沟通协议
- 文档
- 代码贡献指南
- PR审核流程
- 工单流程
- 术语表
- 代码发布
- 操作指南(如数据库迁移、添加密钥)
- 入门
- 安装说明(如Docker、PostgreSQL)
- 预期获取的所有访问权限清单(如AWS、PagerDuty)
- 本地运行应用
- 部署你的第一个bug修复(提示:标记一些工单为"适合新手的bug")
- 新员工会议。你的新团队成员应该与谁会面?
向上管理
- 通过共享一份列出项目优先级、时间表和信心水平的文档,确保你和你的经理保持一致。
- 你的经理也需要向上管理。主动更新你的经理关于项目时间表变更,简要回答以下问题:
- 新的时间表是什么?
- 为什么时间表改变了?
- 你对新时间表有多大信心?
- 没有人在意责备或借口。承担错误并记录你将采取的纠正措施以减轻未来的影响。
宣布变更
- 变更的例子:晋升、重组、结构调整。
- 承认变更的难度或机遇。
- 通过使用叙事来解释原因,吸引情感共鸣。
- 为什么这个变更对公司现在很重要?
- 这个变更影响谁?
- 通过使用事实吸引逻辑思考。这个变更将实现哪些指标?
- 社交化变更以获得支持。从受影响最大的人开始。
站会
我喜欢组织站会,让值班工程师在周一、周三和周五领导。这给了他们练习公开演讲的机会。周四,工程经理(EM)或产品经理(PM)领导站会,讨论优先事项和策略。
周一(值班工程师领导)
- 会前(值班):列出值班期间的重要警报。
- 周末亮点(自由发言)
- 回顾重要的监控信息。
- 回顾值班工单。
- 指出本周计划的任何重大/风险部署。
- 优先事项:本周人们在处理哪些史诗任务?
- 回顾工单看板
周三(值班工程师领导)
- 回顾PR积压和GitHub dependabot问题
- 回顾工单看板
周四(EM或PM领导)
工程经理或产品经理领导站会,讨论优先事项和策略。这是讨论路线图任何变更的好时机。目标是确保每个人都在同一页面上并保持一致。
- 回顾未来几周的优先事项。
- 回顾路线图和任何变更。
- 讨论来自客户或销售的反馈。
- 分享任何有趣的指标。
周五(值班工程师领导)
- 小型自由发言回顾,每个人谈论亮点和低谷。哪些方面做得好?哪些方面做得不好?我们能做些什么来改进吗(如果可以,添加工单!)?
- 演示任何新功能或改进。
- 回顾工单看板。
进一步阅读
以下是一些关于管理的优秀资源:
- 《管理者之路》:各级管理者的优秀指南。
- 《每个工程经理都应该知道的97件事》:来自各界从业者的管理技巧集锦。
- 每个工程经理都应该问自己的5个问题
- 钟摆还是阶梯:关于希望保持技术能力的管理者所面临的挑战。
- 《你的行为造就你的人格》:为什么公司文化很重要以及如何建立公司文化。
- 如何比市场更聪明地招聘:伯克森悖论与工程招聘。
- LifeLabs Learning。为新手和有经验的管理者提供的优秀工作坊。我从中学到了很多关于反馈、辅导和一对一会谈的知识。
- 软件工程师如何帮助面试他们未来的管理者:工程师可以问管理者的问题列表。
- 更好的高管沟通的7个技巧:如何有效沟通的技巧。
- 有毒的会议文化:如何避免会议反模式。