妙谈嘉宾 | LigaAI 军仔、辉哥
特邀嘉宾 | 创蓝云智眭加云
内容整理 | LigaAI
当被问到「为何选择成为技术管理者」时，三位妙谈嘉宾不约而同地表示「不是我选择了管理，而是公司选择了我」；
某位嘉宾更是大胆开麦「要不是担心被淘汰，我肯定不当管理，真的太难了(｀Д´)」。
如果有一天，技术背景的你也「被选择」踏上管理转型之路，你会如何走出自己的「管理花路」？
为了弄清「从技术到管理」的转型与成长， #Liga妙谈第七期特别邀请创蓝云智资深技术管理者眭加云、LigaAI 后端负责人辉哥和前端负责人军仔，以不同视角解读「技术管理者的成长进阶」。
技术背景的新任管理者早期会遇到哪些挑战？新任者如何加速渡过早期阵痛，快速适应新身份？三位嘉宾又会如何解读「技术管理的成长与收获」？下面就随 LigaAI 一起了解吧！
本期内容一览
✨「从技术到管理」会经历哪些变化？
✨ 管理转型进阶：常见的管理难题大解答
✨ 技术管理者必须了解的「快速成长秘笈」
✨ 彩蛋：技术人的宇宙终点是管理转型吗？
01 从「管事」到「管人」的变化与成长
💡眭加云： 我观察到新任技术管理者会遇到几个共性问题。第一，很难凝聚团队；如果是新加入团队的管理者，还会面对团队的质疑和不服。
其次，在处理自己和团队的工作事务时，容易出现资源/任务分配不均。典型的表现是，管理者忙得脚不沾地，但底下的成员很清闲。
还会存在向上汇报和向上管理的困难。新任者缺乏好的方式和技巧，清晰地向上级表达「团队目前需要什么帮助」或者「我们正在遇到什么困难」。
💡军仔： 这些完全就是我的痛点 (TAT) 我在技术从业挺久了，但是当管理还是第一次。原来只需要关心技术解决，考虑具体的问题和细节，但现在要从项目整体规划和战略的角度，思考产品的方向和解决方案。 这对我来说是个巨大的挑战。
尽管成员们都很认可我的能力，但我在「管人」时还是会不知所措。比如我最近遇到一个难题，想问问两位的意见。
❓为了更好地满足业务的整体规划，我提前对研发任务制定了实现目标。但是成员在执行过程中反馈「无法实现」，或者有些人出于个人习惯，选择了能实现功能但不符合我的管理目标的方案。虽然功能实现了，但我很难推进管理工作，该怎么办？
💡眭加云：我的建议是，在不影响项目进度和质量的前提下，你需要给予成员足够包容心。
从两方面理解，一是对代码美观性和质量的包容。 如果成员的习惯影响到了功能质量，一定要及时干预；若只是代码简洁性、美观性等无伤大雅的问题，从技术转型的管理者要能够容忍「不完美」，暂时放下代码洁癖，甚至允许代码存在小问题，保证项目目标的完成。
可以在事后提供改进方案或设定有针对性的、明确的提升目标。技术管理者需要跟每位成员沟通并同步对他们的预期和要求，这很重要；成员能力有高有低，也要结合实际情况设定合理的标准，这是人员培养层面的包容。
💡辉哥： 2019 年刚成为技术团队的小组长时，我也遇到了这些问题。除了加云老师说的「包容心」外，对于意见分歧很大的问题，我还会用「大同小异」的方式，扩大问题的讨论范围，让所有成员参与进来，避免两个人的争论。
另外也要及时调整管理焦点和心态。从前我们更多关注短期的、一到两个迭代周期的技术问题，但管理岗位需要用长远的视角考虑半年甚至一年的工作安排。当你理解和适应视角的转变，就不会一直关注「最细」的内容了。
我一直认为「人员管理」是转型期间最大的挑战，而新任管理者早期很难构建自己的团队领导力。这一点可以从细节入手，比如严格遵守自己制定的要求和标准，以身作则；公开透明地向每位成员传递对他们的期待、评价、嘉奖等等。
💡军仔：我这个角色（技术小组负责人）每天应该做什么事情？
💡眭加云：首先是沟通，包括对内和对外的沟通。 这可能是最花时间的部分；团队越大，花的时间也会越多。
其次是目标的向上对齐、拆解和向下同步。 技术团队接下来的工作目标和重点是什么？围绕确定的业务目标，如何清晰地将信息传递给每位成员，并且保证目标在执行过程中不会发生偏移？这些都是重点关注对象。
第三是关于业务或技术的架构设计和思考；基层的技术管理者可能还需要处理一部分具体的开发任务和需求。
本质上，技术管理者是上层领导和一线开发者之间的润滑剂。你需要想办法取得「上对下」的认可，以及外部团队的认可。这中间，沟通是最重要的。
LigaAI：（申请插嘴）好奇三位老师目前在沟通、目标管理、架构设计和思考，以及其他开发任务的时间占比和分配大概是怎样的？
💡眭加云： 我现在负责好几个团队，沟通会占 40% 左右；目标管理大概是 20%；剩下的 40% 会处理架构设计和其他的事情。
💡辉哥： 我目前沟通大概是 10%-15%；
目标的讨论和管理会多一些，需要跟领导确认后端的规划、对齐季度的产品目标、将目标拆解并同步给组员等等，至少占 20%。
今年也会处理一些突发的紧急需求，或者作为团队的补位接手忙不过来的任务，这部分是 20%-30%。
其他时间都在跟业务、设计沟通需求，了解系统内的所有业务逻辑和细节，占比将近 40%。
💡军仔： 我现在很少执行开发任务，但是会接触核心架构的设计，所以开发时间和架构设计的时间加起来是 10%；每个季度会定期和成员沟通一次。
剩下的时间，我也说不清属于哪一类，就感觉自己一直在协调和答疑：协调其他部门的工作、解答组员的技术问题、理解上层领导的任务……由于组员分散在各个业务小组，我每天还会花时间了解大家做了什么、遇到什么问题、需要哪些帮助等等。
LigaAI： 军仔说自己在跟很多人协调和交流，但是真正分配给「沟通」的时间却是「一季度一次」。似乎大家对「沟通」的理解还有些不一样 (･ω･)
💡眭加云： 我的「沟通」更加广泛，包括对上/对下的交流、跨部门的协调和日常会议、需求评审会等等。
❓场外小互动：你会如何定义「沟通」呢？
LigaAI：今天的三位嘉宾都是从技术转型的管理者。很好奇「从技术到管理」有哪些不一样的体验、成长或者收获？
💡眭加云： 做开发追求解题的「过程」，但做管理更看重「结果」和对业务、对目标的贡献；以前是单人作战，靠自己实现工作目标，但现在必须要说服伙伴们一起为了共同的目标努力。
成长方面，技术的提升路径相对单一，而技术管理的成长和提升是综合产品思维、业务思维、商业思维、沟通能力、决断力等的「全面开花」。
💡辉哥： 思维逻辑上也很不一样。管理者视角会让你从原来「点」的思考，变为「线」和「面」的研究。所以，我现在更重视「重要但不紧急」的任务规划；理解功能和需求时，也会自然而然地思考产品、业务的底层逻辑。
沟通能力和决策能力会得到很大的锻炼。从前需要很多心理建设才能做出决定，而现在更有魄力，也更敢于为结果负责。
💡军仔： 虽然做管理的时间不长，但是我的问题视角也有了很大的变化，并且这种变化和成长可以迁移到生活中。比如，思考问题时不再拘泥和纠结于细节，会站在更高的角度快速试错。
02 那些让技术管理者们苦恼的问题
💡辉哥：「交付业务价值」很重要，但技术管理者如何利用有限的资源，真正带领研发团队更好地交付价值？有时候大家忙了很久，却发现没有在做对的事情。
💡眭加云： 价值源于市场，也服务市场，所以提升业务理解力要多跟市场和产品的伙伴沟通。 管理者需要主动地了解需求的用途，「为什么做这个功能」「它能为用户带来什么价值」，避免将时间和精力浪费在低/无价值需求上。
在此之前，别忘了围绕企业核心价值观和业务目标，制定一套内部统一的价值规范和度量标尺。 举个例子，LigaAI 是一个提升研发协作效率的平台，那么「有价值」可以定义为「新功能带来提效」，拆解「提效」又会产生具体的判断标准和可量化的指标。这些都需要在整个产研团队中达成共识。
价值讨论一定要技术、产品、市场等多方人员，基于统一的标尺和共识，在不断沟通中逐渐明确。
💡军仔：我是一个远程的职能管理者，我的组员们在各个业务小组内工作。有什么方式能让我有效地了解成员们的工作情况？
💡眭加云： 在「职能-业务」交叉管理的情况下，你实际的管理控制力是下降的；可以通过日报、周报，或者来自业务侧的工作汇报抄送，了解大家每天都在做什么。
如果业务团队本来就有开早会的文化，也可以跟业务线的负责人沟通一下信息同步的事情。
💡军仔： 不用日报呀，我们的产品就是干这个的，在【LigaAI 看板视图】里就可以看（不是广告，是真的可以）。但不管是看板还是日报，都只能记录技术研发的工作量，而需求评审、讨论等非编码类的工作很难被记录下来。
因此，我总是无法准确地掌握大家实际的工作量，进而安排新任务。 另外，这些零碎的会议也总让大家无法专注开发，影响代码质量和交付效率。
💡眭加云： 所以你需要主动和业务负责人沟通，明确表达你所希望打造的团队工作氛围，并讨论出一个能让成员专注开发的有效方案。比如说，将某些会议安排在固定的时间段，或者要求一周内的几天要让成员专心开发。
不管是否需要为业务绩效负责，技术管理者都应该为团队提效和产出负责。
💡军仔：你说的很对，我就是要帮助团队提高开发和产出效率。那么，我的工作量和工作产出应该如何衡量？现在减少了开发任务，我经常担心「自己是不是在摸鱼」……
💡眭加云： 前面也聊到，技术管理者的工作重点不是写代码，而是沟通、目标管理和业务理解。所以，你要先转变工作的心态和关注点。
其次要找准自己的定位，理清楚「团队的 OKR 是什么」以及「我怎样可以帮助到组员」。换句话说，要围绕团队的目标，确定自己的管理方向并且制定具体的工作计划。
💡军仔： 那我该怎么跟领导同步产出呢？有时候我了解到成员们很饱和，但是领导觉得「不够」；可是我真的很难再安排新的需求和任务了。
💡眭加云： 领导的「不够」大概率不是「工作量不够多」，而是对团队产出的结果不满意。所以你需要理解领导的目标，减少成员们摸鱼，提升团队的产出。
第一，一定跟领导沟通确认目标并达成共识。当研发管理中出现「质量 or 速度」的冲突，技术管理者要结合统一的目标，做出权衡和决策。
第二，建立有效且实时的成果反馈机制，比如日报、看板；也要主动了解研发任务估算和拆解、项目的人力消耗、研发周期等细节，敏锐地识别「摸鱼信号」。每周定期将这些情况向上汇报，让领导知道团队的进度和成果，以此获得管理信任。
第三，消除效率瓶颈，提升团队产出速度和质量。这又是另一个很大的话题，包括流程优化、生产力工具、更轻便的方案等等。
💡军仔：我现在很难做有效管理 (T∧T) 每当我想组织大家一起讨论产品规划、同步目标，或者开展技术学习和分享，大家总是反馈业务很忙，没有时间，最后我只好直接安排工作。可这样又把大家堆满了，更没有时间提升……（叹气）
💡眭加云 ： 这个问题的解决方案其实已经提过很多次了：主动地跟业务侧负责人沟通和协商，合理分配时间和资源。 你要主动地争取组员的时间，实现自己的管理目标。
如果组员很忙，不太愿意配合，可以通过「问答」或「布置作业」的形式，强硬一点要求大家的回应和执行。这样反复操作形成良性循环后，就会变得轻松。
💡军仔： 技术学习和分享总不好占用研发时间，但真的让大家用休息时间完成我的任务，我觉得也不好。我现在很苦恼：成员觉得自己没有得到成长，但是推进相关的管理动作时，大家又很不积极 (+_+)。
💡眭加云： 如果你过分在意成员的负面情绪，怕给组员「添麻烦」，就会管理得很累。当你确定一项措施很大程度可以提升团队效率，你应该表现得强势一点、心硬一点，坚定地推进管理变革， 不然就会陷入长期熄火状态。「长痛不如短痛」和「慈不掌兵」都是这个道理。
觉得占用休息时间不好，那就更要主动地争取时间。一个沟通技巧是「用好处换利益」，让业务端了解「为什么一定要协调出时间」——因为掌握这门技术，我的团队可以更快更好地交付业务。
对内沟通也需要找准切入点，说清楚能给组员带来什么好处，让他自己意识到重要性。
💡辉哥： 我们之前的做法是在做目标管理时，将个人成长的 OKR 考虑进来，要求 20%-30% 的 OKR 与能力提升和个人成长有关；并且，每个季度我都会跟每个人进行一次交流和口评，分析季度同比情况，再给予建议。
团队里难免会有性格被动的同事，这种方式可以让大家更清晰地感知能力提升的重要性，进而激发自驱力。
03 技术管理者的快速成长秘笈
LigaAI： 新晋的技术管理者怎样才能更快地适应管理转变？
💡眭加云：最重要的是要从心态和思维上做出转变，以及有足够的包容心。
管理不是单枪匹马的个人英雄主义，而是要靠沟通和开会，组织别人一起实现目标和冲锋陷阵。
同时，技术背景的新晋管理者要在一定范围内包容技术犯错和代码不良问题。千万不要一看到成员做不好，就立马自己上手，这个要严格禁止！ 管理者是团队的资源，是军师和智慧星，但不是保姆。
💡军仔： 多跟有经验的大佬们交流、讨教经验；在实际工作中，不要羞于开口，要多向前辈请教好的解决方案。
其次就是抓准管理工作的重点，明确自己的职责，统一整体的目标。如果能做好上和下的目标对齐，后面的工作会顺畅很多。
💡辉哥： 我补充两点，一是要锻炼沟通表达能力，这也是技术背景的新晋管理者的长期必修课。
其次，培养总结和反思的能力，这是很重要的品质。在管理过程中肯定会遇到很多问题，管理者需要深层地挖掘问题的本质，总结和反思，并快速地形成自己的管理方法论，快速成长。
最后，三位妙谈嘉宾也分享了陪伴他们度过管理转型阵痛期的学习书籍。
- 《可复制的领导力》——樊登
- 《突破——程序员如何练就领导力》——刘朋
- 《别让猴子跳回背上》——威廉·安肯三世
- 《细节——如何轻松影响他人》——史蒂夫·马丁 / 诺厄·戈尔茨坦 / 罗伯特·西奥迪尼
彩蛋：技术人的宇宙终点是管理转型吗？
LigaAI：前段时间，网传「鹅厂」首位 Web 前端专家黄希彤因「只做技术不做管理」等原因「被毕业」。大家怎么评价「技术的宇宙尽头是管理」这类观点？
💡军仔： 说实话，当初考虑管理转型时，我的一个顾虑就是「如果不做管理，我会不会被淘汰？」如果能确定不会被淘汰，那我肯定不会做技术管理。
💡眭加云： 我反而认为不管是技术还是管理，在个人目标与企业目标一致的前提下，总可以找到合适的位子，做该做的事。
技术管理的工作围绕业务和目标展开，很少发生个人和企业目标冲突；而技术专家的成长天然地会往个人发展方向倾斜，这可能会与企业目标偏离。
企业肯定希望个人的技术提升围绕企业目标展开，因此当冲突出现，高层管理者就要考虑如何将所有的力量集结到一起；期间，目标不同的成员就会跟大家分开。
💡辉哥： 我赞同加云老师的观点。现在行业竞争大，年龄大的开发者似乎更容易受到发展空间的压缩，而「技术+业务」的管理岗位综合性强，发展空间好，就让大家感觉「管理是中年程序员的出路」。但只要你能力过硬，不管是做技术，还是做管理，都不必太过担心和焦虑。
💡军仔： 哎呀，你们都太官方啦！说真的，公司为什么要招一个年龄大、不能加班、上有老下有小的开发，承担这些风险？
声明：该言论仅代表嘉宾个人观点，与 LigaAI 无关。
💡眭加云： 我挺排斥「程序员中年危机」这类说法的。这两年能明显感觉到行业在大肆渲染焦虑，但从华为、BAT 等大厂的报告数据来看，中年程序员反而是企业研发的主力。
无论是技术岗位，还是其他各行各业的岗位，职场竞争力都不与年龄直接相关，只和能力以及「你能为企业带来的价值」有关。逻辑上，年纪越大，沉淀下来的职场经验也会越丰富，这也是构成职场竞争力的一部分。
💡辉哥： 是的，而且从开发的角度来说，我们更应该消除「中年危机」的刻板印象，不应该给程序员、开发者、技术管理人为地附上枷锁。这样行业生态才会变得更好。
为了进一步了解「开发者不做管理究竟会不会被企业淘汰」，LigaAI 逮住了我司创始人 Ryan。以下是他的回答：
行业内 50 岁 + 仍然活跃的技术专家不在少数。企业招聘看重的是个人能力、思维与企业的匹配度，而不是年龄多大或者头衔如何；无论是技术管理，还是技术专家，能与企业携手并进都是我们期待的伙伴。
>> LigaAI 往期精彩阅读 <<
从 Netflix 传奇看，结果导向的产品路线图如何制定？（上篇）
LigaAI 将持续分享更多技术成长经验、研发效能管理实践，陪伴每一个研发团队和开发者成长。了解更多效能优化与增长干货，欢迎关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。