领导现在想把我培养成技术管理者，更多从事管理方面的工作。架构，代码等执行层的内容让团队去完成，而让我更多参与团队内项目的规划设计，人力的管理，任务的跟踪等。
说白了，工作内容将从之前的写代码，做需求为主，转变为让团队为组织更好的服务，带领团队去完成更大的目标。
乍一看，挺好的一个事儿，随着职级的提高，大部分人都是要从事管理工作带团队的。
我不升上去，怎么能够把业务机会让给更有能力，更有潜力的人去展示自己的价值呢？
所以可以理解为，大多数高职级的程序员，也就是高 p，通常都会走向带团队的路线，也就是管理之路。
所以，管理其实是一个非常好的事儿，但其中也有很大的风险，今天我主要来谈谈风险有哪些：
1、代码水平的退步
由于管理工作的介入，管理者会逐步失去对代码的手感。写代码就跟游泳一样，我们从来没看到过孙杨因为拿了几个世界冠军后就不用再训练了，只要他比赛，就一定要训练，写代码也同理。
除了自己写代码，还要读代码，读优秀的代码，做到读写结合才能让自己的代码功底越来越好。
但管理者更多的时间不是在执行层面了，而是在宏观层面，脱离代码一段时间以后，必然会失去这一部分的掌控权。
2、履历变得空洞
做一线程序员时，我们能够往简历上堆各种框架，开源技术，编程语言，设计模式等等。
做了管理以后呢？变成了：
我带领团队取得了 xxx 的成绩；
由于 xxx 项目，我将团队效率提高了 xx%；
我及时识别了 xx 风险，更换 xx 方案，带领团队转型成功；
在我看来，这些技能在一家公司能够成功，在另一家公司却不容易复制。因为团队业务，文化，市场，平台，这些东西不一样的话，很难重复取得好的效果。所以如果去面试，不一定取得好的结果。
当然也是有例外的，比如有公司在组建一支这样的团队，想做类似的一款产品，那么我就有机会顺利切换过去。
但找工作，讲的还是概率，工作技能可以覆盖更多的公司，那对于我来说机会也就越多。
3、进大厂更难
上个月我去字节跳动面试了一把（我去字节跳动面试了），发现他们考察的是很基础，很基本的东西。加上对其他大厂的一定了解，我认为想去大厂工作，技术上的根基是一定不能丢的。
做了管理之后，由于代码不像以前那样可以经常练习了，框架原理也没时间撸了，这些对于想去大厂都是很减分的。
大厂招高 p，底层核心的东西是绝对会被问到的，除非这个领域面试官不懂，他想招一个人过来领路。我有个朋友就是这样，他是业内的专家，但是常年不写代码，不过还是被招进阿里，领导也是看中他在行业的影响力，想做这个事。
其他业务线的程序员呢？还是得老老实实在代码，架构，技术上精进，才能赢得大厂青睐。
既然识别到了这些风险，又该如何破局呢？
我觉得可以从以下方面入手：
1、保持写代码的节奏
做了管理以后，并不是就不能写代码了。如果完全没时间写，那我认为要么是自己偷懒，要么是管理得不够好。
优秀的管理者，会找到一个科学的方法让自己减少对团队过多的关注时间，同时还能让事情按计划稳步推进。
这样就能抽空写写代码，就像锻炼身体一样，保持一个身体状态只需要每天跑个 20 分钟即可。
2、多了解开源框架
做业务的时候，更多时间是服务于需求的，这会让业务一线在一段时间里没有时间了解更多的新技术。
管理者在把控好整体团队目标以后，就可以抽空多去看看现在最新的技术，他们的应用场景，是否可以引入到团队项目中来，并以此作个可行性分析报告。
这能够保持技术 online，也能在技术架构选型讨论的时候提出更多自己的意见去供团队参考。
其实我以前对后端技术了解不多，但团队在规划一个新的自动化平台时，我抽空翻阅了不少热门技术，也作了一些可行性评估，这让我在之后团队架构讨论上也提出了一些建议，其实是有收获的。
3、温习基础知识
一些管理者在接手管理工作以后，需要经常参加会议，沟通技术方案，或者评审需求。虽然代码能力有所下降，嘴皮子的功夫确实是得到了很大进步。
但我认为还是要抓技术的基础，这些东西或许在业务一线的时候就没有太多时间补齐过，而通过温习基础知识，是一个非常好的让自己保持面试竞争力的方式。
我是这样认为的：如果留在当前的公司，一直做着管理工作，并且有很大向上空间，是没问题的，但是考虑到将来跳槽的话，必须得保持自己的技术基础和技术敏感，也算是始终给自己留一条后路，因为将来，谁都不知道会怎么样，只要公司不需要你了，砍掉是绝不手软的。
今天谈的都是做技术管理的风险，并不是说管理没有好处。实际上好处非常多，我自己接触一段时间以后其实已经有所体会，待我进一步摸索出管理的一些科学的方式方法，再来同各位分享~
源自公众号 henryWoo