Leading Snowflakes｜工程师转管理者必读管理技巧与团队领导策略解析
针对工程师转任管理者的迷茫与挑战，整理9大管理课题，从时间分配、决策检视、团队沟通到招募与扩充，提供具体方法与工具，帮助提升管理效能与团队凝聚力，实现带领团队成长与技术视野扩展的目标。
Click here to view the English version of this article.
點擊這裡查看本文章正體中文版本。
基于 SEO 考量，本文标题与描述经 AI 调整，原始版本请参考内文。
Leading Snowflakes — 阅读笔记
“Leading Snowflakes The Engineering Manager Handbook” — Oren Ellenbogen
管理职，初来乍到，一切都很迷茫；对于管理的知识只有汇整之前的工作经验、观察或与其他同事闲聊时获得，知道主管做了什么事底下的人是正面的、什么事是负面的；也就大概只有这些经验想法，知识是破碎的，没有一个有系统理念，于是我开始看书，开始记录一下每个作者的经验；如果遇到相同的事物，有了「知识底气」之后就不会在手忙脚乱了。
Leading Snowflakes
作者在过去近 20 年的工作经历中，从原本的软体工程师一步步踏入管理职；担任过不管是大公司或新创公司之 Technical Lead、Engineering Manager；本书详细点出从工程师踏入管理职时会遇到的瓶颈及该用什么方法整理、解决。
我觉得与我的背景非常相似，都是本来做软体开发，初探管理职；借由书中提到的重点让我学到很多可以怎么做的方法！
- 本文仅为个人笔记夹杂些许个人观点，在这资讯碎片化的年代，强烈建议要自行阅读过原文书，才能有系统的吸收精髓。
- 笔记的意义是之后回头来看，比较容易快速定位到想复习的点。
- 部分内容直接摘录原文。
Lesson 1. — Switch between “Manager” and “Maker” modes
从工程师(Maker)到管理者(Manager)的过渡。
完成好任务甚至优雅地解决难题是优秀的工程师的衡量标准，但做为管理者以不是用完成任务的能力来衡量，这部分我们已经证明过了，而是以带领、推动、提升能力的团队目标作为评断标准。
但也不能完全将自己从任务中抽离，完全与任务细节抽量导致与团队成员断开连结，对于执行成果、优先权、信任方面长期来看会有很大的风险。
所以不是说当管理者就不用做工程师的事，而是两边都要碰，需要的就在 工程师(Maker) 跟 管理者(Manager) 之中取得平衡。
做为工程师时我们喜欢有连续不被打断的时间让我们保持在 Context 中去解决困难的问题；但做为管理者时，我们需要的是时常跳出来帮助团队、关心队友，所以被打断其实是管理者的工作之一。
但我们同时需要身兼工程师和管理者，那该如何是好？
作者建议建立两个 Calendar ，一个是 as Maker (工程师)、一个是 as Manager (管理者)，然后每日一大早给自己 15 – 30 分钟整理思绪，安排本日行事历，该做什么事、有什么会、有哪些空档的连续时间点可以拿来解决任务(as Maker)。
作者的行事历范本
我们也需要专心的时间
作者所述，现在身为管理者，但我们仍需同时处理任务；可利用的空档专注时间对我们来说比以前更重要。
作者提到，可以在需要专心的时间透过一些动作传达给队友，暂时不要打扰我！
方法有：到会议室、戴上耳机、或甚至买一个 ON AIR ! 的开关灯放桌上。
如果不是紧急问题，可以先请队友留言或汇整资讯寄信给你，等到专心时间结束后再来处理。
评估自己做为工程师的时间能解决的任务
因为已经不像以前纯当工程师(Maker)的时候可以全心全力灌注在开发需求上，所以要依照工程师行事历所能运用的时间来选择能亲自执行的任务。
不要成为团队的技术瓶颈，我们的任务是提升团队能力、探索新技术、提升公司对外或队内的技术视野；可做的事有预先研究技术问题，然后与队友分享并交由队友执行、解决公司技术债、流程问题增加开发效率、使用新技术、将公司技术开源、开放 API、对外黑客松…等等。
最重要的还是平衡
作者建议可以从 15–20% 比例开始调配，本来是 100% as Maker，现在可能是 20% as Maker / 80% as Manager（但这要看实际团队大小及成员能力，作者也说 50% / 50% 也有可能），就是不能在是 100% 投入工程开发，要多花心力在管理上。
善用 1:1
定期与队友 1:1，互相 Feedback 并分享所学到的东西。
如果管理者的任务吃掉你所有时间
作者最后提到，如果你管理的任务太多完全无法做工程 (as Maker)的事，与任务、技术脱节时，可以考虑每周选几天 WFH 与公司隔离或参加黑客松。
Lesson 2. — Code Review” Your Management Decisions
定期 Review 你身为管理者下的决策。
身为工程师时我们有很多方法或工具，只要遵循就能提升好能力，诸如 pair programming、code review、design pattern；但做为管理者，尤其菜鸟我们感到相当孤独。
我们不想承认对上或对下一无所知、害怕为团队成功负责也担心没拿捏好技术(债)与商业需求之间的平衡。
作者提到要跨出去寻找提升管理能力的，公开征求 Feedback & 提高管理技能的方法；做管理者时也能像做工程师时的热情。
记录＆回头审查决定
同事与老板都是我们很常低估的强大资源，我们可以快速的从同事与老板的 Feedback 中学习；建立好纪录＆回头审查决定的习惯，可以让我们更好的得到 Feedback。
作者提到：
「There is no one right way, there are only tradeoffs.」
我想也是，如果不是进退两难的问题应该也不会问你；如果问你就代表队友不知道该如何决定。
我们可以列出选项并提供决定给队友，但与此同时也要记下所做的决定。
作者提供的纪录 Sheet 范本
养成纪录的习惯，并且要确保内容是之后能回忆的。
作者建议，每个月回头审查，可以与老板或其他管理者或其他同事分享讨论决策（至少要分享一半的问题），听听别人的看法；可以匿名保护当事者，对事不对人，并记录下来。
回头审查时的要点
关于问题：
引起多少技术问题？
是个人问题？
只是某个成员的独立问题？（是不是单纯只是他不了解目标？）
这问题在其他团队或会重复出现吗？
关于决策：
这问题真的需要管理者来决定吗
有没有问过队友的建议
有没有其他比较有经验的人能提供建议
现在重新思考，还会是同个决定吗？
Lesson 3. — Confront and challenge your teammates
推动队友跳脱舒适圈以及不让自己变成混蛋跟陷入陷阱。
作者提到一开始很不习惯，因为本来是朋友的同事现在变成部署；他害怕会伤害本来的关系；所以一昧地承担所有收尾的事，但最后他发现他越是保护越与队友距离越远，因为他一而再的埋头苦干，少了分享让队友失去信念。
回头来看，作者说与其害怕伤害队友的感觉不如说出内心真实所想的，「害怕伤害队友」这单纯是自己自私的想像，没有必要；而且这是身为管理者的责任，带领团队成长前进；要远观大局、控制风险。
分享真实想法对双方都很难，但这是身为管理者的责任。
我们要展现同理心而不是同情心，为了让他们的工作真正出类拔萃，他们需要我们客观的意见。
作者提供以下三个要项让我们能在情绪与行为中做出平衡：
我有展现出同理心吗？
我有清楚说明我的期待吗？
我有以身作则吗？
「If you want to achieve anything in this world, you have to get used to the idea that not everyone will like you.」
如果你想要有所成就，就必须习惯不会每个人都喜欢你的想法
四个常见的陷阱：
相较于掩盖，我有公开分享失败经验吗？（可以是写文章、寄信给所有人）
忘记统整讨论结果（要习惯纪录 1:1、讨论的结果）
使用错误的 Feedback 媒介，没得到真正的问题（依照团队文化找到适合的 Feedback 渠道，EX: 1:1）
不即时的 Feedback 我们需要注意，工程师喜欢挑战自我、提升技能，同时也想要获得尊重、主管的 Feedback；我们的任务就是带领团队成长，所以在每次有 Feedback 机会时不应该拖延，因为不做决定也等同于做决定；而且一旦 Feedback 的风气衰弱之后要再点燃就更困难。
Summary
可以花时间写下激励队友的方法及询问主管是否太保护队友？
Lesson 4. — Teach how to get things done
如何以风险较低的方式完成任务。
以身作则是不错的方法，时不时参与团队的开发示范如何计划、产出好的功能展现我们想传达的理念；另外要注意，在这其中要多说 Why? (为何这样做)、少说 How? (该怎么做)
作者提到极度透明的文化，让团队成员有完整的 Context 能提高推动决策的能力。
降低风险
为了降低产出的风险，作者建议将需求拆成许多小块迭代功能；并将此想法与其他 Team 沟通分享。
Scale and performance — always have a backup plan 这功能会不会影响效能(或造成其他问题)？可以提前知道吗？有没有备案(开关)；在没有备案之前宁可不要实作，因为会影响团队信心。
将任务拆解成小任务，降低 Deadline 风险 一开始可能很难，但可以训练学习
善用同侪压力 将任务拆给队友共同协作，彼此共同努力(Code Review 亦也是)
持续对内及对外沟通 对内：确保期望、同步、Deadline、资源，对外：沟通、如果时间很赶了可推掉不重要会议
支援、修 Bug、文件 不是释出功能就好，还要做好客服支援、修 Bug、还有文件
做好回顾及委派任务，提供其他人领导机会
挑选几个能以身作则的 Task
询问队友学到的东西、能让他更积极的动机、讨厌的事
Lesson 5. — Delegate tasks without losing quality or visibility
委派任务的同时又不丧失品质跟能见度。
身为管理者必须做好任务委派，作者认为委派就该设定好期待并相信被指派的队友有能力执行并是有机会学到东西及保有发生错误的空间，管理者另一方面也要保护队友来自公司的压力。
作者使用以下表格进行记录：
这边主要纪录的是对团队目标重要的任务，日常工作不用纪录。
- Must 写下任务内容
对于是否要将任务委派给队友，作者会先问这个任务是否真的只有我能做且是属于管理者该做的事，第二个是这个任务是否是长远的领导任务；如果都不是则委派队友执行。
对于要委派的任务可评估队友的经验、技能，找到合适的人选。
External 关于外部或上面期待的资源 (Feedback/Tool)
Delegate
Delegate 的部分，我们可以提供一页的 Paper 阐述我们的期待、简单的范例。
Lesson 6. — Build trust with other teams in the organization
团队与团队兼协作的默契。
作者阐述，组织为了能做更多事会拆分很多小组进行快速决策处理；对于各小组的方向定义其实不难(EX: iOS 就是做 iOS App)，难的是要对齐所有小组的目标。
小组越多就很难统一所有人的价值观、期望、优先权、隐含的期望。
应该要关注拆分小组的理由跟动机而非产出，否则可能导致矛盾。
作者认为要对齐各小组的方向有以下方法：
团队要有愿景，而不是只把任务处理好
管理者需要区分出需要与想要
优化团队更快的完成正确的事而不是完成更多的事
与其他团队经理建立良好的沟通 作者建议可以在每两周的管理者会议分享团队内的状态、分享自己团队阻碍与痛苦、接下来会做的主要任务、做的原因
与其他团队对于优先权意见不同时，可解释引出其他因素（EX: 这个做了之后，可以降低 CS 客诉、一劳永逸、加乘效果…）
先了解外部团队需要我们帮忙的地方并且主动密切追踪
再来提出我们团队需要外部团队帮忙的点
列好需要确认的清单，确保在会议上有讨论到；如果没有可以在会后拉相关的经理讨论看有没有其他可能
若不可能则要权衡可能会延迟时间或替代方案，并要让关系人知道（防止在背后指指点点）
一切都是权衡
另外还有 5 个让队友能与其他团队建立密切关系的方法：
简单的感谢信（感谢协助）
交换团队工作
内部技术年会，互相分享
一起观察使用者使用状况，一起脑力激荡提出优化方向
邀请一位其他 Team 的队友加入我们的工作
Summary
「 imagine that someone from Team A drops a feature that Team B needs, due to an urgent support issue. Without communicating this priority change to Team B, trust will be decreased even if it’s a justified priority change.」
「 difference between transactional trust and relational/emotional trust 」
了解交易信任与关系信任。
交易信任 — — 人们是否会履行承诺并完成任务
关系信任 — — 人们是否以建立和保护关系的方式行事
Lesson 7. — Optimize for business learning
建立商业学习文化而不是建造文化、优化吞吐量、优化的价值。
过早的优化是灾难
优化当前问题为重，不要为了优化而优化
即使不是整个专案的负责人，我们仍可就内部运作进行优化，大的成功多半来自小部分的优化累积
身为管理者我们必须展现决策背后的动机
建立商业学习(价值)文化大与建造文化（重点不是建造解法，而是我们试图解决的商业问题）
优化效率 vs 优化吞吐量问题： 优化效率：解决单一 task 的时间 优化吞吐量：一个时间范围内(EX: 一季) 能解决多少 task
知道每个优化的 Impact，
自动化的重要（能一劳永逸节省时间）
使用 AARRR 原则为价值优化：
Acquisition：如何引入更多使用者
Activation：如何引导使用者完成让他了解产品价值的任务（EX: 闹钟 App，新手引导他完成设立一个闹钟）
Retention：提升回访率，回来使用次数
Referrer：让你的使用者、内容，带来更多流量
Revenue：数字化评估使用者带来的收入
这五项息息相关，如果因为 Retention 低，可能可以同步调整 Referrer、Acquisition。
身为工程管理者，我们要做的不是埋头写 Code 或是全心投入在技术；时不时应该要重新对齐产品价值。
当产品还在草创初试市场状态时，应该要以优化效率(快速解决任务释出)为主，重复著以下流程：
功能能提升 Retention -> 释出功能 -> 学习 -> 调整＆重复。
评估功能到释出每个阶段可以优化的地方（花太多时间在设计？在讨论？）
可以投资 20% 时间减少 80% 的开发时间吗？尤其是令人痛苦的点
可以先实验或发布给最小受众吗？避免功能很大包结果最后没人用。
- 要做好数据追踪，才能了解努力的成效
「If you can’t make engineering decisions based on data, then make engineering decisions that result in data.”」
虽然相较「这功能不做，公司会倒闭」跟「这功能会导致技术债」，前者当然更可怕；对于技术债，作为管理者如果能争取更多时间解决我们应该就要做到，我们应该要做好沟通及控管。
优化可能不会用到的程式意义不大。
过了草创试验期，产品模式趋于稳定；这时候比较适合优化的是吞吐量(EX: 给定 X 资源，得到 Y 产出)
给予商业需求可预测性(同上)
追踪团队产出 (EX: 「01/01/2013–14/01/2013: 2 Large features, 5 Medium features, 4 Small )，经过长期统计；可以借此提供预测。
找出＆解决瓶颈：
同步的沟通：例如产品开发流程，需要设计资源；在进到工程开发阶段，我们是否已经有明确的规格可执行开发？还是在等待？还是有什么我们可以先做的？
基础设施：让程式码好扩充、好维护
自动化：使用自动化处理繁琐的人工操作，节省时间之余也能避免出错
因为商业策略随时在改变，我们应该对于优化策略保有更开放弹性的想法，优化的总结还是以商业需求为主。
Lesson 8. — Use Inbound Recruiting to attract better talent
关于招募。
平时就要开始做以下事项，防止突然缺人才要开始，那只能回到传统找人方式，不停的面试但却很难找到合适的人。
对内：
培养良好的工程文化环境 (EX: Code Review、年会…)
打造吸引人的工作环境
像经营品牌一样
团队成员共同努力
加强人与人的连结（EX: 庆生）
先让成员是对团队感到骄傲的
对外：
内部团队每周定时对外回答社群问题 (EX: Stackoverflow. . )，加强曝光
在程式中隐藏招募彩蛋(EX: 网页开发者工具)
与社群分享我们团队遇到的问题及解决方法（文章 or Talk）
举办黑客松
建立 Side Project (EX: 开源专案)
分配以上各任务给团队成员，大家一起为找到好人才贡献一份心力。
Lesson 9. — Build a scalable team
打造可扩充的团队。
建立可扩充程式以是我们之前担任工程是该有的职责，但现在要挑战的是打造可扩充团队。
不像程式，人有期待、需要、梦想要顾及。
作者想要打要一个快乐的工作环境、队友之间了解任务的期待、新挑战；而且要能持续保持这份热情。
对齐目标 对齐个人愿景与公司目标，如果不了解当前公司的目标很可能造成团队功能失调。
对齐核心价值 算是共识及默契，对于做事方式、什么重要的默契；团队核心价值也不是一成不变，要与时俱进。
平衡 对于团成员的职能、成长，分配不同的愿景、自主权、拥有全；互相协作一起成长(EX: 新人只期待能了解公司做事流程，老鸟要 Code Review、指导)；每个人都应该要有成长性。
团体的核心价值观大于个体 可能导致有人离职，也需要时间耐心才可能实现；也有许多挑战 (EX: 有人离职时会质疑核心价值)
成就感 成果要能有成就感，做为管理者不能让队友干烧热情
实践
定义团队愿景 EX: 作者的团队是做爬虫的，他的团队愿景就是「To build the largest, most informative profile-database in the world.」 请注意是愿景，不是短期目标也不想做的事。
定义团队核心价值 在挑选核心价值时可以「这个价值重要到会因为没有而开除某人吗？」 写下核心价值、原因。 作者提供以下几个他写的核心价值：
- 不要让别人(其他团队)来收拾善后，自己(团队)的错误自己要承担
- 对团队所有成员保持忠诚尊重 有了核心价值在招募或开除更有评断准则，还有更能有做事的基准。
定义成员对团队对管理者的期待
提供具有生产力且开心的工作环境
知道 Task 的 Why 而不是 How
能够得到真实的 Feedback
有机会带领其他成员
能够分享工作成果
定义对团队成员的期待
基本期待：
完成任务
保持学习热忱
保持分享、教学热忱
知道做事的底线 sense
个人期待：
依照能力设定期待
有能力训练他人改变
推动改变而不是抱怨
我们是团队，团队成员有自己的责任跟要交付的成果，同时也要与其他人协作，帮助他人，互相成长；定义期待像是种契约，在原本的同事关系变成管理者关系之下，能更好更有目的的领导；定义这些项目不容易，需要时间、耐心去迭代。
「You can’t empower people by approving their actions. You empower by designing the need for your approval out of the system.」
有任何问题及指教欢迎 与我联络 。
本文首次发表于 Medium (点击查看原始版本)，由 ZMediumToMarkdown 提供自动转换与同步技术。