技术管理者(如技术总监、技术VP、CTO等)和技术专家,都是从技术专业人才提拔而来,尤其是技术专家,100%以前是技术专业人才;技术管理者虽有特例,但是也是极少数,非常非常少,因为技术的特殊性,其他行业的管理人员是很难带好技术团队的。
技术专家,一般是在作为技术专业人员的时候,体现出来利用技术解决问题的突破能力,能做别人做不了的事情,那么在公司发展的过程中,他们会被提拔,给予更大的平台,以便更好的发挥他们的专业能力,HOLD更大、更复杂的技术架构。
技术管理者,原来也是技术专业人员,技术做的好,业务熟悉,产出高,那么公司自然希望整个团队也像他一样,所以他就被逐步的提拔上来,让他带领整个团队更高效的完成任务,让整个团队更好的发展。
我们可以看到技术管理者和技术专家的共同点,比如都是做的好,希望发挥更大的能力,逐步被提拔,做的好,再被提拔,就像压力测试一样,不停的加压。
虽然有很多相同点,但是他们区别也很明显,比如技术专家,他的日常工作都是对事的。
相比来说,技术管理者的工作就是关于人的,如何让团队发挥出更高效的能力。
从以上对比不难发现,技术管理者是驱动整个团队来做事情,除了必要事情之外,大部分的工作都是对人的,而技术专家更多的是以完成一个个事情为目标,在这个过程中,技术管理者会为其传递业务意图、提供资源支持、协调其他团队的沟通、确保任务的完成。
对于以上概述,可能会觉得技术管理者比较好做,其实不然,因为这个过程中有很多取舍。
比如产品在发展,但是我们已经知道未来的方向不是这样,产品的技术架构需要改造,才能适应未来业务的发展,你该怎么做?这时候要做的绝不是仅仅的集中人力,进行大面积的改造,因为这样会导致业务停止不前,现在不是十多年的产品研发,动辄可以半年甚至一年的封闭开发。对于现代的互联网,可能2个星期的时间都没有,必须每星期,甚至每天产品要有变化。
所以技术管理者这时候需要做的就是取舍,是兼顾,要保证现有的产品业务不受影响的情况下,抽调少量精干人员进行技术架构改造,并且还要分一二三四期,尽快的上线验证,通过这种方式,逐步的把旧的技术架构换掉,达到适应未来新业务,兼容老业务的目的。
技术人员最喜欢新技术、新架构、新研究,但是作为技术管理者一定要克制、要忍,不能头脑一热,冲上去什么都不顾了。以随手记的账本改造为例,我就是在兼顾业务的情况下,抽调几个精干的人员进行底层账本架构的改造,让新的架构可以满足我们多场景账本以及灵活自定义的需求,这也是网上经常被提到的边开飞机,边换引擎!
对于技术专家来说,协调可能不是强项,尤其是跨大部门的协调,这时候技术管理者要在这方面帮助他,拉通两边部门的配合,剩下的事情就是他们自己去完成了,最后最好跟进和检查。这也是技术管理者关于「人」的一部分工作。
和人相关的还有很多,我再举一个例子,我在17年升任开发部门经理后,发现一个现象,整个公司的前端人员是分散在各个组织架构中的,一个小组2-3个,这样就有很多问题,比如:
基于以上问题,我把公司的前端整合成了一个前端组,任命了一个专门的前端经理,让这个经理带着整个前端,进行技术的升级,比如引进VUE,积累模块等,从而提升开发效率,节约人力成本。
到现在,以前的前端组已经成了前端部门,下面有4个前端小组,积累了自己的前端组件库,可以很方便的用于H5、小程序等各个项目中,大大提升了团队技术和工作效率,团队成员的个人水平也提升了,不再像以前天天做产品任务,个人技术无法提升了。
这就是一个很好的例子,可以更好的区分技术管理者和技术管家的差别,对于技术管理者就是要能发现这些问题,提前布局某些系统、技术和组织架构,也更好的支撑团队的发展,业务的需要。
对于技术管理者,刚被提升这么高岗位的时候,可能还会遇到一个问题或者困惑,就是放不下技术架构。这个困惑我以前也有,从18年开始,我逐步的放手了一些具体技术、架构的设计,交给团队的骨干、架构师和经理人来承担,我更好的为他们提供资源服务协调,让他们能更好的做好安排的工作。
这个过程可能会有一些问题,比如你觉得交给其他人来做,没那么放心,或者他们做的没那么好,这时候你可能会着急,我的经验是,只要大的方向没有偏离太多,让他们多试试,尽可能的不要在中间干涉太多,但是要阶段性的检查,这样他们才能成长,团队才能更强大。对于技术管理者,不一定要求团队成员完美,只要每次能比上次好一些,进步一些,就好很多了。
技术管理者不是要做技术专家的工作,而是带好他们,服务好团队,让整个团队可以容纳更多的人发挥出能力,这样整个团队才会越来越强大,才能更好的赋能于公司业务的发展。
本文为原创文章,转载注明出处,欢迎扫码关注公众号
flysnow_org
或者网站asf https://www.flysnow.org/