距离上一篇博客已经过去三年多了，并不是自己惰性，而是我几乎把所有精力投在了工作上的思考和总结。要说这三年干嘛去了，一句话说是做技术管理去了，值得为自己总结沉淀下。
如何 Landing
作为之前的一线大头兵，只虚线带过2~3人，突然跳槽到新的环境，空降带团队，而且还是第一次实线带人，第一次负责 10+ 人的团队，第一次管理异地团队。这三个第一次无疑给我增加了更大的难度，提前有预期刚开始的几个月会面临很大压力。
在入职后的第二周，老大就让我出差去深圳认识团队。我的团队除了我，其他人都在深圳，10+人其实是两个小组分别支持两条不同的业务线，都属于业务前端开发。在一个周会的场合上，老大正式介绍了我，然后团队成员分别做自我介绍，团队就算正式交给我负责了。在轮流介绍的过程中，还有个小插曲，有两位同学都表达了前端没有技术含量的观点，还有位同学说了一些更直白的话。我只能以我过去的经验向他们表达了“做好前端不容易”的观点，说了两句后就 close 此话题，场面有一些尴尬。
1. 先了解业务
无论何种岗位，我认为在新人 Landing 阶段都必须先了解公司业务，而了解公司业务最快的方式是看公司内部的培训课程。中大厂内部都有丰富的视频和课件学习资料，这些资料往往质量很高，可以快速让我了解公司的主要业务和所在行业的行业知识。
作为研发岗位，熟悉所负责项目的最快方式是查阅过往的产品需求文档。要先了解所负责项目/模块在全局业务中处于什么位置，然后再挑选重要的项目/模块逐个查阅产品需求文档，特别是从0到1的那种大需求文档。
最后，根据学习金字塔理论，将自己学习到的行业知识、业务知识、项目概况等分享给其他人，先整理下来，找机会讲给别人听。
2. 同时熟悉人
我是一个 I 人，学生时代还很内向。对于我来说，熟悉人比熟悉项目难得多，但这两件事必须同时做，因为 Landing 时间有限。现在回想起来，我当时用了两个方法来熟悉人。
第一个方法是用奶茶、家乡特产来刷脸。记得刚接管团队的第一周，我就买了喜茶一杯杯送到每个人座位上，记得多买两杯带给合作的后端、客户端 leader 顺便刷个脸熟。第二次去深圳出差时，我带了好多特产的饼和糕点，给自己团队以及合作的后端、客户端团队每人都分了一点儿，给做 leader 的每人一小盒。其实都是10元左右的小特产，图个诚意，我是新来的前端 leader。
第二个方法是借助熟悉人来熟悉业务。因为其他人在公司的资历都比我深，对业务和项目的演变都比我了解更多。有了上面的刷脸后，我就“好意思”去请教别人了，比如 APP 里哪些页面是 native 哪些是 H5，怎么申请一个线上环境的测试账号，公司的研发流程中会涉及到哪些人等等。有问题就不只可以问自己团队的小伙伴，还可以问其他团队的小伙伴。我不认为问一些类似“项目怎么跑/测试环境怎么调试”这样的问题很低级，这反而是作为 leader 应该去了解的，并且让以后的新人不再有这类疑问。
最后，因为我们公司的组织架构关系是不公开的，无法看到其他团队的组织架构，所以日常中接触到的人只能自己记在心里或小本上，包括在一些群里看到的消息，他负责什么、他是不是 leader、什么样的问题可以找他。时间长了后，可能需要积累一年，工作中接触到的大部分同事我都大概了解他们的职责和上下级关系。
3. 了解诉求，解决问题
上面提的“熟悉人”更多是对合作团队的，这里“了解诉求”主要是对自己团队。在刚接管团队时，就做了些功课，团队成员每个人的毕业时间、学历、司龄、以及前任 leader 对他们的评价。在接管后的两周里，陆续与他们每个人都做了一次 one one，询问他们目前的工作范围、有什么想吐槽的、以及有什么自己想做的事。有些同学说的都是很个例的事情，我只能给建议，有些能帮的我尽力解决问题，有3个例子很值得拿出来一说。
1) 有一个同学反馈电脑太卡影响工作，想换电脑，但流程卡在 IT 运维那边。我一顿询问后，问到了公司电脑换领的要求，电脑也确实符合要求，事实上从电脑生产日期起已超过三年、但从电脑开始使用起还未到三年，所以一开始卡了流程。最后 IT 同事也答应了可以换电脑。另一个同学反馈手机测试机申请了一年都没申请到，就这个事，我也向上反馈了后来碰巧跟上了申请窗口。
2) 还有个同学表达了自己想学习，但不知道怎么样学才能不脱离实际工作，希望 leader 能够以身示范。这位同学也是第一次见面时说前端没有技术含量的，我有去看过他的代码，相当一部分 Ctrl+C/V，我认为这是极不负责态度的眼高手低。我挑了比较常见的表格增删改查场景，封装了一个类似 ProTable 的组件，建了组件库的 npm 包，写了组件库的文档和规范。可见当时团队的前端技术有多落后，这么多 Ctrl+C/V 的代码，团队这么多人竟然没有人尝试改变现状。我做好示范后，再让这位同学在具体页面中迁移并给组件库做补充。
3) 还有一位同学，可能因为工作才半年，在做一个从0到1的项目中遇到了不少困难，上线面临风险。我得知后一起介入了这个项目，从需求文档看起，先帮着一起解决测试阶段的问题，保证需求能够交付。后来我也一起参与了线上问题的排查工作，梳理页面流程的关键逻辑以及收到线上反馈时的应急方法。而对于这位工作才半年的同学，我让他一起参与了团队公共函数库的梳理，夯实下基础，之后去做其他相对稳一点的项目。
我借用前同事的一个观点来总结，就是不能只想着高大上的工作，要能够把手伸进下水道里。了解团队内的诉求，从问题切入，尽力解决问题。这几位同学，可能是团队里最先开始对我产生信任的。
4. 执行团队规范，全员参与建设
根据前面与团队每一个人的 one one，我有两个不同的业务小组，存在一些共性如下。
如图都是团队小伙伴向我表达的意思，基本确定了我接下来至少半年要重点推动的事情。
- 技术任务：在产品需求之外争取技术任务，逐步清理项目中的包袱，把项目标准化
- 组件积累：团队没有沉淀，先从组件库、函数库开始逐步积累，减少低级的 Ctrl+C/V
- 分享机制：能够“分享”是比较高效的学习方法，既利于自己提升，又利于活跃技术氛围
最后能不能落地，执行力怎么样不好说，因为团队才刚开始，我通过团队规范和制度来执行。规范主要是一些文档约定，例如：新人 Landing 流程，需求研发流程，代码分支规范，生产发布 SOP 等。
规范主要为了减少犯错，制度是执行力的关键。我刚开始定了这些规矩：周二周四晨会，周五周会，周会分享制度（每周2人轮流）。周会分享强制执行了3个月，轮了两圈，每人都参与了两次分享。关于上面说的技术任务，刚开始我也是强制指派的，每个人都会被分到一项需求以外的技术任务，一轮结束以后才变成认领制，让优秀的同学有机会发挥。
Landing 总结
空降 Landing 的三个月，很累也很欣慰，我的团队跨出了第一步，先“有”：组件函数有地方积累，项目优化有文档输出，线上问题有日志可查。虽然这3条放在其他公司其他团队来看，都上不了台面，但是通过自己的努力一点点将团队带到这里，也让我对我的团队有了更大的信心。有了“有”，后面才会有“快”和“好”。
如果要一句话总结第一次做管理如何 Landing，就是坦诚相待，做 leader 不是当领导，帮助团队一起做好事情。
第一年：走出技术蛮荒，团队技术转型
走出蛮荒：两大问题
1) 开发体验差
正如前面 Landing 阶段提到的“技术任务”和“组件积累”，为什么要做这两件事呢，根本原因还是开发体验太差了。早期团队中的项目全靠 copy，一个项目 copy 另一个项目都不带删代码的，一个页面 copy 另一个也不带删变量的。这也造成了需求做不完，技术没成长，后期维护难的恶性循环。
当时公司的大前端部也刚成立不到半年，也在推进前端工程化，工程化的第一步是标准化。标准化不光是靠文档约定，而是要靠流程靠工具自动化来保证更高的执行度。我们也跟着部门的前端改革节奏，将项目逐个迁移到前端工程平台。同时通过定制一些 webpack plugin 来保留部分存量不规范的代码，保证增量页面增量代码是符合最佳实践的，这样我们的开发体验就会逐渐好转。
2) 排查问题难
我的团队所负责的业务前端有个特点，就是页面分散、访问量大、问题反馈也多，甚至有些 H5 页面在业务核心流程中。线上问题反馈通常只有一句话描述，好一点儿的带个截图，问题处理群大多会先拉客户端和前端同学。甚至不夸张的说，有些奇葩的问题需要加用户微信后单线联系用户协助排查。
我刚入职时，我的老大就安排我参与前端监控的建设，我主要负责写捕获日志的 SDK。正好排查问题是我们团队的刚需，就从这儿切入，把我们组所有 H5 项目都做了接入，也提炼出了一些监控上报的最佳实践。同时总结出一些常见的排障方法和经验，在组内做了一些培训，组内有位同学还写了一个快速查日志的工具命令，最终我的团队基本全员都具备了日志排查能力，部分同学能够结合前端和后端日志一起分析问题。
直面挑战：两个里程碑
好景不长，我转正后没两个月，上面就传达了一个巨大任务，技术中心要做好一条全新业务线的产品 MVP，说是公司已经定好开城日期了，线下已经多少钱砸下去了。幸运的是我团队里有一位老员工被“钦点”为 C 端前端 owner，也因此有了更大的挑战，当前连产品需求文档都没有，距离老板定的开城日期只剩 45 天。
这种活儿肯定会越做越多，而且在开城日之前还会有一些模块需要提前上线预热。我当时做了个决定，把原本团队里小组1的6个人分出3个人去支持新业务，其中有一位就是 C 端前端 owner，要负责安卓端、iOS端和微信小程序三个端的用户核心流程，他再带个人跟着他一起干。最后再留一个人，我和他一起支持需要提前上线的功能和页面。
以下是我那一年在公司 gitlab 的记录，5月到7月是最令人崩溃的三个月，坦诚来说这是我工作至今压力最大的三个月。
同时期也是公司产研快速扩张的阶段，一方面新业务的研发资源很匮乏，基本每个周末都在加班，必须优先为新业务招人。另一方面原有业务也在提出新的项目，原来被我拆分的小组也需要继续补人。我曾经两个月面试了 62 个候选人，最多的一周 5 天面了 11 人。
这一轮爆肝后，完成了两个里程碑
- 新业务顺利开城，零延期，零故障，业务数据也远超预期。
- 在招人时我有意侧重 Vue、React 双技术栈的候选人，借助增量项目增量页面，团队完成技术转型。
第一年总结：建立信任
第一年过得很快，总结下来就是四个字“建立信任”。从团队的问题出发，让大家相信并看到一点点的进步，逐步完成转型；把挑战视为锻炼团队的机会，和大家一起冲锋陷阵，克服挑战也是相互信任的结果。
第二年：务实结合务虚，打造团队房子
争取前端话语权，提升团队 Owner 意识
第一年接管团队刚开始从每个人的诉求出发，制定出了后来推进的事情。第二年我又回到了人身上，我们推行的事情最终不仅仅是完成事情，更重要的是通过事情让人的能力得到提升，这样说得功利一点才能够升职加薪。或者换种说法，人成就事情，事情成就人。
在公司大前端部成立之前，前端同学在技术方案上很少有话语权，基本就是产品说做成什么样就做成什么样，后端同学说接口怎么样就是怎么样。有了第一年的技术储备后，我们是时候去改变这个局面了。我在团队里提出了一个口号“做靠谱的工程师，与业务共同成长”。这里我在工程师前面刻意抹去了“前端”，意思是不要把自己局限在前端，要以工程师的角度去思考和解决问题。同时不要想着脱离业务的技术能够高大上，技术必须结合业务、服务于业务，人、技术、与业务共同成长。
这个口号的具体落地，就是让前端同学担任需求的技术 Owner，职责是开发前牵头整理需求的技术方案，开发中推进上下游问题的解决，开发后与各端研发拉齐发布方案。刚开始我们以为如果涉及后端、客户端工作量的需求，前端同学无法胜任技术 Owner，确实术业有专攻。但经过一年时间后，团队里有一半同学都有能力做好需求的技术 Owner，部分同学甚至对复杂需求也能游刃有余。当然，做这个角色要比普通参与需求交付花费更多的精力，我们也会挑选那些后端逻辑不是很重的需求来让前端作为技术 Owner，在涉及前端的产品需求中我们前端担任 Owner 的次数占比可达 15% ~ 20%。
这个事情除了数字上的体现，我认为更重要的意义是让大家明显感觉到了前端和以前不一样了，前端同学会对产品交互提出自己的观点，会关注需求在业务层面的逻辑，也会和后端同学 battle 某个接口设计是否合理。只要前端有一定工作量或有一定历史包袱，我们在开发动手前都会整理前端技术方案，无论前端是否作为 Owner。名义上的 Owner 变得不再重要，而是我们是否像 Owner 一样做事。
成果不够轮子来凑，既要又要还要
这一年里我们团队技术产出最丰富的一年，当然就如前面所说，这些技术产出都是结合业务服务于业务的。
1) 提效工具
提效方面的小工具可能是大部分开发同学最喜欢造的轮子，我在团队内坚持了一个方向，小轮子可以造，但必须要收敛在一起。之前有同学尝试做了一个 Chrome 插件，用来开发联调阶段的账号登录，我们可以在此插件上继续丰富，涵盖开发、联调、测试、线上各阶段经常遇到的因为没有工具而显得低效的事情。
- 开发阶段：各项目入口；接口文档转 TypeScript 定义；产品埋点搜索（埋点代码 -> 集中搜索 -> 跳转埋点平台）
- 联调/测试：一键登录；过期 token 自动刷新；编译后 ESNext 提醒（项目用到的依赖里可能存在 esnext 代码，造成用户低端机上直接全屏
- 线上排障：case 反馈一键查询；前后端日志关联（从前端日志关联到后端日志，方便全链路排查）
以上这些小工具都不是同一个人做的，而是以功能为单元，谁想到了 idea 就由谁负责实现，由好几个小伙伴共同贡献的。
2) 体验优化
在体验优化方面也体现出了团队合力的作用。首先是对前端性能的度量，组里有同学对此很感兴趣，帮助我们调研并实现了 FCP / LCP 指标的采集，补全了前端监控 SDK 在性能方面的指标。接下来，基于页面渲染的指标，组内开展了各种项目性能优化，优化手段也多样化。
- 纯粹构建时的优化（分包、按需），能提升 FCP，但对 LCP 可能不敏感。
- 大图片优化（优先 webp），优化接口调用时机（减少阻塞），可以明显提升 LCP。
- 对于有固定入口的页面，可以上离线包，是提升 FCP 和 LCP 的必杀技。我们改造了多个项目后的经验数据为 FCP 平均提升 60%，LCP 平均提升 40%。
组内还有同学尝试了不一样的渲染方式，可以使用 SSG (Static Site Generation) 构建时渲染，虽然项目是 SPA 单页应用，但仍然可以在构建阶段将落地页的 DOM 内容直接输出到 HTML 中，特别适合于有落地页的场景。
从构建时渲染的思路继续延伸，对于动态内容的页面，我们可以使用骨架屏代替真正的 DOM 内容直接输出到 HTML 中，我理解骨架屏也是一种构建时渲染。如何生成一个页面的骨架屏，也有同学把它做到了上面提到的 Chrome 插件里。
3) 前端稳定性
我从入职到现在一直负责着前端监控 SDK 的维护工作，这一年更多结合实际业务场景做查漏补缺。
- 对于大范围问题：站在业务开发视角，对架构组输出的前端监控指标进行补充和共建，比如说指标里区分接口 host、区分来源页面，以及前端关键操作的成功率事件上报，这些都是在业务侧十分需要的监控指标。
- 对于个例问题：除了时间、地点、人的信息，还有其他信息也可以帮助我们排查业务反馈的 case，比如客户端信息、接口返回内容等，也把用于前后端日志关联的全链路 traceID 在我们组的前端项目中最先应用。
我们团队也是最先在前端项目中用上了告警能力，借助公司 CI (核心基础设施) 部门提供的监控平台能力，以及前端监控服务输出的前端指标，我们沉淀出了“前端告警 -> 监控面板 -> 查日志”的完整排障方法。
第二年总结：收获与遗憾
至此，在团队小伙伴们的共同努力下，我们建成了团队的房子图，在做好业务的前提下追求体验和效率，而稳定性是公司技术的底线，九层之台，起于累土。
当然，这一年也有很多遗憾。比如上面图中关于效率有一条“关注联调时间”，是指我当时强调了“联调、debug 投入的时间占比”不超过 25%，事实证明没有任何作用，既浪费大家时间统计工时，又没有达成这个 25% 的指标，本身一个人一天的工作时间就不可能只做一件事。
还有，由于前一年公司产研扩张速度太快，这一年有不少人员流失，其中不免有可惜离职的同学。此外，我所提倡的“前端 Owner 意识”可能让部分同学感到太卷，最终在绩效考核时很难客观量化，造成部分同学过程很辛苦、但与结果略有落差。以上这些都是我管理上的失误，在下一年要特别注意。
第三年：充分授权，用数据抓过程
设立实线小组，用数据来管理过程
刚接管团队时有10+人，扩张后最多时有25+人（包括外包同学），经过一些缩减和人员流失后，我的老大把另一个5人小组合并到了我团队，保持了接近20人的团队规模。当然，合并了新的小组也意味着又多了一条业务要支持，目前我们团队共支持了三大不同的业务，对接来自4个二级部门的后端。因此，我也在团队内划分了4个小组，每个小组人数都差不多，并且让小组长都作为实线管理为小组成员的绩效负责。
这一年我主要跟进4位小组长，通过他们来推进各事项的落地。这一年我开始重视过程数据了，过程也要想办法量化，哪怕结果不如预期，通过过程数据也能做出客观评价，并从数据中发现新的问题。
典型例子是关于“开发质量”，由于前一年我过于关注“联调、debug 投入的时间占比”没有任何作用，我的出发点是提高开发效率，bug 越早发现，修复 bug 的代价则越小。因此我开始抓开发质量，用小组“人均 bug 数”的指标来衡量，目标是平均每个人每个月不超过4个 bug（测试阶段提的 bug）。乍一看这个指标很反人类，特别是与测试同学的部分指标完全反着来。
但事实上，我们基本做到了 bug 数收敛。特别是有一个5人小组，在上半年有人一个月能写出10多个甚至20来个 bug，下半年人均 bug 数减少了一半，小组整体也达成了我定的目标。我想表达的是，开发质量是一个过程指标，开发质量的提升反映出团队成员在需求理解、方案设计、沟通协作、自我要求各方面的综合提升，我们使用的办法只是提倡动手前先梳理技术方案、提测前先保证自测检查，这同样是“做靠谱的工程师”的延续。
重视问题复盘，用机制来保证执行
这一年出过很多线上问题，也有影响面非常大的问题上升到了公司高层。痛定思痛，我必须重视每一次问题复盘，让团队在问题中得到成长。关于复盘，首先要定一个复盘文档的模板，如下。
1 | 1. 问题描述 |
可以看到，我们对于前端引起的问题也严抓数据，影响面要能量化，这并不是对“出锅”同学的惩罚，而是让锻炼他分析问题影响面的能力，需要一定的日志排查和数据统计/估算，也让他更对线上问题更加敬畏。
其次，我们对问题原因有更多剖析，进而可以做出更加成熟的改进措施，改进措施也要具体、可执行、可验收。比如说“Code Review 要更仔细”就是一句空话，而“Code Review 中增加 XXX 检查点（甚至融入 git 工作流里）”则是具体的改进。
最后，对近期一段时间累计的线上问题做集中回顾，发现其中的共性，共性原因的改进措施能否融入每一个人的日常工作流里。我从组里十几例线上问题中发现有一半是因为需求理解不到位、改动范围未同步给测试同学，还有少部分是未做好兼容引起的问题。因此我推动了在前端技术方案模板中增加对常见兼容方案的 Checklist、以及对改动范围的明确列出（包括页面和公共组件），也在技术方案中提前考虑可能发生的线上问题和应急措施。
最近有发生一例问题早在一个多月前就有人反馈了，当时我们也安排了同学去排查，但因为只此一例没有足够重视，一个月后反馈突然增多。因此，我开始要求各小组长用在线表格记录日常收到的各类问题反馈，既可以追踪问题跟进人的排查进展，也可以对问题进行归类以发现潜在的优化空间，每周 review 表格避免问题扩大，这也是用机制来保证执行。
前端稳定性从规范化到精细化
上面写的两条大多依靠小组长来落地，这一年我剩余的个人精力主要在前端稳定性。一方面因为年初团队里出了很大的“锅”上升到了公司高层，另一方面我始终参与着架构组的前端监控建设，是时候站在大前端部门的角度来看稳定性这件事了。
1) 规范化：来源于业务，落地到业务
仍然从问题出发，究竟哪些前端页面出问题后会引发舆情和严重后果，按影响程度梳理出了部门所有前端项目中的 P0 和 P1 核心页面，并按业务线和页面维度将前端监控各指标汇总在一个监控面板中。基于前端核心页面，逐步建立起前端稳定性的流程规范。
- 发布前：前端研发全流程规范，其中前端技术方案模从我们组内推到了部门其他前端团队内。
- 发布中：前端生产变更规范，其中借助核心页面的稳定性保障，在部门内拉齐了H5页面灰度放量的操作 SOP。
- 发布后：对于监控工具更重要的是什么情况下应该用什么工具，针对大面积问题、个例反馈问题、非稳定复现问题这三类问题的排障思路。
除此之外，基于实际业务排查过程中的痛点，提炼与稳定性相关的辅助工具，比如灰度放量中的项目分版本监控、基于告警消息的异常日志统计面板。这些都是既来源于业务，又落地到业务。
2) 精细化：主链路监控，未雨绸缪
如今我们所做的产品越来越复杂，小程序已占据了C端的半壁江山，主链路监控不全是后端的事，前端也需要在主链路上做更精细的监控。
典型例子就是微信小程序中的“手机号授权”功能，从2023年9月开始按调用次数收费，同时2023年下半年微信平台也前所未有地加大了对小程序用户隐私和数据规范的执行和判罚力度。这也带来了新的稳定性风险，原本“白嫖”的“手机号授权”功能，现在既可能欠费，又可能被微信封禁。更要命的是，“手机号授权”功能一旦不可用，前端根本不会请求到业务后端，在微信授权阶段就直接返回失败了，这也体现前端监控的必要性了，是对全局服务监控的一种有效补充。在前端根据微信授权 API 的回调结果，上报成功率事件到我们的前端监控，可以获得比接口调用量更加精确的监控指标，并为之设置较为敏感的告警阈值，因为它会直接影响用户的登录和注册。
在过去的几个月里，我们多次通过前端告警发现了微信小程序“手机号授权”功能因业务场景违规被微信封禁的情况，并借此推动部门各小程序做好对微信登录违规的技术预案。对业务来说微信也属于第三方依赖，第三方依赖必须可监控、可降级。当我们组负责的小程序第二次被微信封禁“手机号授权”功能时，做到了5分钟内告警发现，10分钟内完成应急快恢！完全不亚于核心后端服务的应急响应能力，这是我在两年前根本不敢想象的。
第三年总结：开始真正管理
回顾过去三年，第一年主要在建立信任，通过一同战斗、团队技术转型来建立起双向的信任。第二年先描绘团队愿景，把愿景具象为团队的房子和基石，并做出实打实的事情。那么第三年则是开始真正管理，通过组织架构上的管理授权，靠过程数据和流程机制来作为管理抓手。
第三年的团队产出并没有第二年那么丰富，但我认为这也是里程碑式的一年，我的团队做事风格从广度开始转向深度。程序员越往后发展是靠深度，也体会到管理越往后是靠流程。
我理解的技术管理：利他
曾经的我喜欢看讲成功学的畅销书，但最后只有一本书的一句话深深留在我心里，它就是《稻盛和夫的人生哲学》里反复出现的一句话「作为人，何谓正确」。稻盛和夫这位经营之神，他是材料研发出身，后来创业自己经营，带出了两家世界级的企业，这句话是他早期指导自己做决策的理念。这句话让我很震撼，大道至简，哪怕没有任何经验，从人之本性出发，根据普世的价值观来做判断，也一样能带好团队。
我刚开始也是借用「作为人，何谓正确」，把自己带入事情的当事人，去想应该怎么做。我们公司内部也有很多管理培训的资源，建团队、定目标、追过程、拿结果，每一块都能展开成一门课程，都有具体的做事方法。方法可能非常多，能掌握和用到的很有限，但我猜测所有方法的最顶层都是某一个或几个理念，理念的数量不会太多。就像管理大师德鲁克的名言「管理是激发人的善意」，背后也是利他精神。
虽然我作为实线管理团队有三年，但是在第三年才开始真正做管理的事情。我当前对技术管理工作的理解也是“利他”，这里的“他”泛指我的上级、下属、以及合作伙伴的团队。
- 对上级：要了解上级面临什么样的挑战，发生什么样的问题连我的上级也兜不住，我当前面对的事情如果站在我上级的视角他会怎么看。
- 对下属：了解下属对工作和生活上的期望，不要让无谓的“卷”成为主流，而是做真正对他职业发展有利的事情，哪怕不能升职加薪，跳槽也能有更强的竞争力。如果遇到只想躺平的下属，那就通过流程约束适当提高要求，只要保证不掉队，不被末位淘汰。
- 对合作伙伴：了解合作方的主要目标，对问题有同理心，在守住自己原则底线的前提下尽可能为他人想办法。当然这不是一味的舍己为人，而是有原则讲道理，维持互帮互助的关系。
最后，己所不欲勿施于人，想对他人提更高要求，首先自己要做到自律。Keep moving!