转任管理岗位后，还要不要从事编码工作？

随着工作年限的增加，不少工作出色的小伙伴就会提拔到 teamleader 的位置，带领大家做事，角色发生转变后，相应的职能也会跟着改变，以前只需要对自己负责，现在要对 team 负责；以前只对事负责，现在要对人对事都要负责。可想而知，压力陡增，经历过这种变化的人相信更深有体会。

最大的变化，是自己的时间被瓜分的七零八落，真正属于自己的时间几乎没有了，需求评审、设计评审、接口讨论对接、计划评审、UI 评审、产品迭代总结、公司业务讨论、每天早会等各种会议；邮件处理、电话接听、微信沟通等等，各种需要响应；张三来请求这个问题自己解决，李四过来问这样做行不好？总之，一天下来，自己的事基本进展，程序员与产品之间有个笑话：“不要跟产品经理聊天，你跟他扯一天，他需求清晰了，你的工作什么还没干呢？”是不是有同样的感觉。

特别是技术出身的小伙伴，依旧会保留一些开发任务的习惯，这样做对不对呢？为保持编码能力，这样做无可厚非，但要注意几点：

1. 任务量不能太大，很有可能因时间不足而完不成。

2. 任务紧急重要程度要把握好，不能成为迭代完成的阻碍。

3. 任务尽量耦合性低，别人不依赖你的功能，也可以轻松进行

4. 可以从别的小伙伴任务中分摊，即便自己没有时间处理时，也不影响此任务的达成。

5. 技术攻关可以做，尽量别影响日常团队协作

走到此岗位的小伙伴，经过一段时间的磨炼后，都会产生一个想法：还不如回去做我的开发，做完任务交差，现在到好，一天天事事的，基本没什么自己的空间、时间，从早到晚，也不知道忙个啥。想法有归有，但人要成长，必然经历一些蜕变，不能遇到困难就退缩，不然这个坎永远也过不去。

刚走到管理岗位的小伙伴，还要不要编码呢，视具体情况而定。初次转型后，未来的前景依旧充满不确定。如果丢下技术，后期换个工作环境后，如果能从管理做起最好，如果不能的话，还是要回到开发一线从事编码工作，还能不能保持不中断的捡起来呢？如果继续做管理，必定需要填补很多软技能技术，如沟通技巧、协作合作、团队领导等等，必然会挤压技术精进时间。

有个万无一失的方案：不丢下技术，时不时做一些编码工作，哪怕是在业务时间，哪怕是做 Code Review 也是可以的。如果你笃定将来向管理岗转型的话，那脱离编码是早晚的事，但要确保能在管理职能上精进很大，但这依旧充满不确定性。

有个千万不能做的方案：自己把编码工作安排的满满的，基本不花时间在团队管理、成员沟通上，这个团队肯定不会走的长久。时间分配上必定是团队多个人少，七三开或者八二开，甚至九一开都行，角色决定了你必须以团队绩效说话，而不能看个人能力突出与否。你必须成就他人，才能反回来成就自己。

最后，祝你编码顺利。

拓展阅读：

厉害的程序员都有自己的商业模式

软件生命周期与技术人的职业周期

【技术&管理&业务】我们该做何抉择？

技术人要懂商业

学习新技术时你应当掌握的『最少必要知识』

什么时机学习一项技术最高效

一线人员忙着学习技术，二线人员忙着技术变现

突破自己的技术思维