著作权归作者所有。商业转载请联系 Scott 获得授权，非商业转载请注明出处[务必保留全文，勿做删减]。程序员的青春饭，有人说是 30 岁，有人说是 35 岁，现实是这样么？真写不动的时候，要不要转，什么时候转，怎么转？
2018 年，刚好工作 8 年，也是我而立之年，在 30 岁这一年我从技术研发全面的转向了技术管理，经历了一个夜夜深思夜夜失眠的阶段，今天把我的思考结果分享给大家，包括身边的一些人一些事也会贯穿在本文之中，尝试给大家梳理一些选择之前需要考量的因素。
在开始之前，先送大家四句大白话：
- 了解了解不停去了解
- 规划规划不断做规划
- 执行执行绝对要执行
- 回馈回馈坚持做回馈
其实按照池老师的处事三原则就是：闭环、谁难受谁推进、Think Bigger，换做是我自己的方式，总结一下，就是不断去了解自己，不断去修正规划，不断的推动执行，不断上下左右回馈，如此反复再无它。
做技术到底是做什么
未来机器会取代我们，就像年轻的工程师会取代我们一样，凭借更佳的脑力运算凭借更低的应用成本，那我们当下做技术到底是做什么？
工程师赖以生存的技术，是驱动这个世界发生质变的核心推力引擎，它的本质是创新也就是再造，通过消耗我们的脑力去更好的消耗计算机的算力，脑力换算力成立的前提是脑力可以做更多意识层面逻辑性的情感性的决策，可以通过强大的抽象能力分析事物的本质，而算力目前还很难做到，等到机器可以做深度抽象做自主决策的时候，就是脑力编程下岗的时候，那时候就要依靠我们人类无穷无尽的想象力与创造力来输出规则给机器，机器帮我们做最优决策和过程实现。
回到当下，最优决策和过程实现还必须靠我们这一代人，而做技术就是在做决策和付诸实现，只不过我们凭借特定的语法规则给机器编写特定的执行任务，而语法掌握的熟悉度、技术运用的熟练度以及对机器和规则运行作用过程的理解程度决定了我们的技术实力是处在哪个段位哪个 Level。
Java 的语法有它特定的结构，PHP/Python/Javascript 统统不例外，这些特定的语法规则和结构我们都可以通过记忆烂熟于心，而它们背后的技术思想，基于它们衍生的特定框架，结合它们所形成的特定语言工具生态，对于这些的熟悉程度又进一步决定了我们运用技术的灵活程度，至于对机器和规则的理解则取决于我们训练大脑的深度和广度。
看到这里，我们再来看技术二字，就很容易明白它无非就是一些技巧规则的运用，而我们常年累月所浸泡的技术体系里面，经常面对的恰恰就是这些技巧和规则，编程经历越久，对于技巧掌握的越多，对于规则理解的越深刻，基于技巧和规则我们能衍生出的再造能力也更强，而通向更强再造能力的过程中，我们做技术的本质就是不断训练自己的大脑熟悉这些技术体系，建立新的认知体系，再创造出新的解决思路和应用方法论，所以到最底层的时候，比拼的还是想象力和创造力，只是很多时候我们空有想象力和创造力，却缺少让想法落地的技巧和规则运用能力，原因在于我们训练的还不够深刻，还不够丰富，也就是量变不够充分，质变也就很难发生，做技术本质就是 架构、编程和运维保障，架构就是训练出来的脑力逻辑性，编程就是规则和技巧，而运维保障则是规则应用的土壤，把它们拆解一下，就是下图上的一些技能点：
至于如何通过技术训练我们的大脑，实际上就是如何保持技术的快速成长和持续成长，我们前文有过相关的讨论，在这里我强调一点，技术需要持续性的时间投入来训练才能保持一定速度的成长，一旦投入中断，或者投入强度变小，很快技术成长就会降速，甚至没踩上行业趋势的话，会被同行甩在后面，作为这个小话题的结尾，我举一个身边的案例：
有一个同学 13 年毕业，进入大公司历练 2 年，技术趋于资深，后来高薪跳槽到一家创业公司成为核心骨干，创业公司发展迅速，1 年内就有了将近 10 人的前端团队，就任命这个同学成为技术 TL 带领团队，但快速膨胀的业务线迅速吃满了该同学的编程和架构时间，业务越来越多团队越来越大，他也就半推白就的走向了管理岗位，2015~2016 年起 React 进入蓬勃发展的时期，也是 Node 开始大规模应用的时期，他身不由己的松懈了对于技术深度的精进，到 2018 年时虽然薪资拿的较高，但原有的技术体系与当下的技术栈已不合时宜，编程的综合能力也快速下降，更重要的是，他内心依然向往编程，对于技术管理并没有建立太浓厚的兴趣也没有积淀太多成熟的管理方法论，后来痛定思痛，跳槽出来，降薪 30% 进入了一家公司做基础架构，技术重新捡起，降薪是因为他的技术能力已经低于市面行情所需求的实力，从 18 年到 19 年，他越来越开心，虽然薪资还没当年拿的多，但技术总算慢慢追赶上来了，所以，技术的精进需要持续的投入，如果中断就很快掉队，在切向管理的时候，一定要深思熟虑三思后行。
做管理到底是做什么
技术是以熟练的技巧和规则为基础，靠兴趣、想象力和创造力驱动，那技术管理是做什么呢，把管理丢开只做技术可不可以？答案是可以，答案同时也是不可以，可以还是不可以要分阶段来看，在职业的早期阶段是可以的，在走向资深的阶段后就不可以，因为管理不仅仅是以人为对象，包括自己包括组织，包括一件件复杂的事情和合作关系，都需要具备管理能力，为什么需要管理能力，是因为技术编程现在已经进入了深水区，光具备 编程、架构和运维实际上只是具备了基础能力而已：
抛开基础技能还需要更多其他的综合能力，假如业务走在最正确的方向，确定最合理正确的指标，运营收集到最客观真实的客户反馈，产品规划出最直击用户心灵最命中业务痛点的产品路线，产出最完整最闭环最精准的 PRD 文档，UED 同学设计出最符合用户需求最契合 PRD 文档的设计稿，服务端提供最稳定最明确的接口稳定和接口联调环境，项目经理把握最稳妥最可控的迭代节奏...在这样的环境下，有可能你能专心的写代码不需要跟各方有太多纠缠，可是试问下：这个 “最” 字有几个人可以做到，你经历过这样超高命中率超强配合能力的团队么？任何一个环节出岔子，就可能代码编程实现中的重大干扰因素，这还仅仅是对于一个人是如此，如果 10 个人前端团队，每个人都处在这种不稳定的状况下呢？
其实我们都处在一个个不完美的公司，一个个不完美的团队中，即便如 BAT AMD，又何尝没有道不完的心酸，团队越大问题越复杂，而作为技术管理者，职责就是解决团队中出现一切问题，并能促使团队不断的变得更优秀，前文我们讨论如何带领小团队时有张截图，这是小菜前端早期的一个阶段：
其实一个团队出问题的时候，是远不止上面这些问题的，当这些同时出现交叉出现的时候，团队的技术管理者应该做什么呢？答案就是发现问题、定义问题、制定方案、解决问题、复盘总结，发现问题是最容易做的事情，团队中大家的吐槽随时都是发现了问题，但定义问题则是一个更重要的能力，如何准确的定义问题直接决定了能否制定出正确的应对方案。
我们再把上面的其他综合能力做个分类归纳，会发现如下特征：
所有的这些能力集合，都可以成为管理岗需要的能力，只不过我们所认为是管理是比较狭义的管理能力而已，它的对象更多在于组织内部的向上向下和向左向右。
这时候我们也就意识到，管理所涵盖的的确不仅是事情，而是将所有能力综合后完整的推进路径，简言之就是驱动团队的方法论，方法论是可以训练的，但这些方法论往往跟编程本身没有关系，方法论投入精力越多，编程参与就越少，这就是技术向和管理向的天然矛盾，但方法论的背后反而有很多通用套路是对编程也是有益的，比如 PDCA 这样的做事规划模型，我对它做了改进，加入了意愿和能力的维度：
尽然技术路线与管理路线有矛盾也有统一，但最终它们通往的方向不同，我们在做职业转型的时候，就必然要取舍，就必然会经历内心的煎熬，就必然在某条路上愈行愈远。
管理能力一定是加分项
看完前面两个论述，我们会觉得管理好像不是一件很容易做的事，也不太像是一个对很工程师生涯很友好的选型，事实上，在整个市场的技术岗位稀缺度上，技术管理者与技术专家是同样的稀缺，无论这个同学技术是一般般还是非常好，身上具备管理能力一定是加分项。
因为技术团队是最好带也是最难带的，好带是因为技术同学的单纯与淳朴，难带是技术同学的天真和不成熟，一个好的技术管理者可以把团队打理的井井有条，发挥更大的效能，让业务方爽的不要不要的，团队成员也都能不断的获得成长，而一个不合格的管理者则会把团队搞的乌烟瘴气、怨声载道，甚至跟业务方无法建立信任关系，这对于一家企业是灾难性的后果。
因此用人方任命技术管理者，宁肯不求有多完美的果，却希望不要有太多的过，因为一旦技术团队与公司之间撕裂或者内部撕裂，整个公司将付出更巨大的资本和时间成本，来再次把团队校正到正确轨道，而由于技术团队是公司最贵重的资源，这个技术管理岗就至关重要，这就解释了为什么它是加分项。
最后一个观点，技术管理一定离不开技术二字，一个管理者可以不再精通技术，但要对技术有充分的经验积累和敏感度，要具备比较成熟的技术评估和技术人才运用的方法论，一定不可以抛开技术，纯粹从业务和人的视角做管理，比如用强 KPI 强指标的考核，或者只追求短期业务实现而不顾及长期基础设施建设和技术栈的迭代升级，那样对于技术团队的长期人才体系会有很大的伤害。
技术生涯跟天赋强相关
技术天赋越好的人，技术价值最大化的成功率越高，在技术的圈子里，技术成就能有多大，的确是因人而异，是有天赋因素加成的。
其实十几年看下来，真正在纯技术领域走向成功的人并不少，但前端这个领域却凤毛麟角，通常达到阿里的标准 P7 专家水平，就已经是大部分人的职业天花板了，还有少部分人能继续攀登到 P8 高级技术专家的高度，再往上走，就往往跟技术编程本身关系不大了，这也是为什么大部分人到了 P7，年龄也大都接近 30 岁上下，会慢慢转向管理，一个是市场需求大，一个是自己的职业天花板在这时候就遇到了，毕竟背后付出的心血都是脑力和身体。
所以，如果我们发现自己的技术天赋很高，那么可以尽量迟一点考虑管理，如果技术天赋一般，那么可以早一点理解管理的意义，并做一些必要的准备，将来迎接这个转型。
什么时候该考虑做管理
往往你做管理的时候，会源于一些外力，比如你跳槽去了一家新公司，刚好有这个管理岗坑位，比如你在本岗位干的风生水起，老板比较挺你让你带俩人试试，比如公司组织架构调整，你是被动任命，比如你所在团队老板离职，你临危受命等等，很多时候你从技术开始转向管理，都有一些机缘巧合，不知不觉就半只脚迈进了管理的池子中。
而你身上一定有了管理的标签，你就不再是一个人走，而是带着一群人走，你不再是对自己负责，而是对大家负责，你不再是仅仅面对业务，更是面向组织，可能就是这一夜之间，你的使命已经发生了根本性的跃迁，可是往往你要过很久才能慢慢明白过来。
这样的管理，其实是大部分人遇到的，也就是被动式的考虑，被动式的征召，而转向了管理，其实最好的管理路线，其实也是最好的技术路线，都跟我们前面提到的能力和意愿强相关，我们意愿上愿意转管理喜欢做管理，那么可以切换，如果意愿上极度排斥，那么就要深思而行，那怎么判断自己是喜欢还是排斥呢，我拿几张表格给大家测试下，看你喜不喜欢做这样的事情？
是否喜欢推导人的做事动机，是否愿意用这样的图来复盘自己和他人的项目过程，看所有人的能力和意愿处在哪个区间：
是否对商业模式感兴趣，愿意花时间研究不同行业不同公司不同团队，他们的成长情况，包括自己团队的成长阶段：
是否喜欢对问题进行分析归类，从人、事、组织等多个角度来抽象问题本质，并且有足够的热情去推动解决：
是否对于管理的手段，管理者的定位，以及所有公司决策层下发流程的执行力度有自己的分析，有更客观的评估：
是否真的愿意花时间去理解使命愿景价值观，人的道德品质和内心价值取向这些务虚的东西，是否认同人的驱动和需求层次与管理者胸怀及成就他人的关系：
以上这些事情与编程几乎无关，大家如果毫不排斥甚至喜欢，那么我认为当你的技术到达了技术专家的时候，或者再晚一点，都是可以考虑转管理的时候了，如果继续走技术路线，那么相信这些感兴趣的分析也会帮你更好更客观的分析所处的环境与所能发挥的价值。
小结
技术研发和技术管理有很多不同，但并不冲突，甚至在一个人的职业生涯中，二者的定位和比重也会来回切换，那是因为技术总是在急速的变革之中，只有积极的跟进技术浪潮，对技术保持较高的好奇心和敏感度，才能更好地做技术管理，同理在一直追求技术造诣和工程师价值的路上，也要时不时培养训练一些基础性的管理能力，至少是管理意识，这些软实力可以成为你当前岗位内推进各种疑难事项的润滑剂，同时也为将来的另一个职业路线打下一些基础，总之，技术路线与工程师创新价值的长远实现是贴合的，而技术管理与商业、团队和组织能力成长更贴合，两者在少数人身上可以很好的整合，形成软硬兼具能虚能实的综合竞争力，而我们大多数人，可以让自己在两个方面都不要有明显短板，才能在长期的职业生涯中，总能收获期许的回报。
Scott 近年面试或线下线上技术分享，遇到太多前端同学，由于团队原因/个人原因/职业成长/技术与管理通道，甚至家庭城市等等原因，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，大家可以找我聊聊南聊聊北，对工程师的宿命和价值有更多的看见与了解，Scott 微信： codingdream，也可以来 关注 Scott 跟进我的动态。