写点什么

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

用户头像
MavenTalker
关注
发布于: 2020 年 04 月 29 日
转任管理岗位后,还要不要从事编码工作?

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


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


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

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

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

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

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

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


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


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


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


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


最后,祝你编码顺利。


拓展阅读:

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

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

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

技术人要懂商业

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

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

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

突破自己的技术思维


发布于: 2020 年 04 月 29 日阅读数: 675
用户头像

MavenTalker

关注

大龄程序员 2017.10.28 加入

公众号( 码闻强识 )作者

评论

发布
暂无评论
转任管理岗位后,还要不要从事编码工作?