当上Leader后,为啥投身技术的时间更长了……

kevin 2023-11-05 11:53:00

 

导言

 

定下这个题目的时候,脑海中闪过那些小组长、技术总监以及CTO等技术Leader的工作方式,也回顾我自己带团队的过程中,工作方式上的一些变化。作为一个技术领域的Leader,应该具备什么样的素质,如何领导好技术团队,拿到技术领域的结果?技术管理者应该管什么,如何开展工作?

 

一些技术Leader在工作中只会上传下达、摊派任务,即使贵为大型团队CTO的角色,也经常听到“我是CTO,不是和你们讨论技术方案的,我要的是结果”这样的话。作为一个技术团队的Leader,真的是只要关注结果,而忽视其他吗?

 

图片

 

一、技术视野

 

当今的技术日新月异,技术的更新迭代日益频繁,技术Leader作为小组/团队的带头人,需要解决团队中核心的技术问题,或是带领团队为团队提供解决问题的方向。具有一定的技术视野和技术敏感性,这是作为技术领域Leader的Baseline。

 

技术Leader须技术基础扎实,同时眼界宽广,在自身专研的技术领域,熟悉从工程、数据到AI完整的端到端解决方案细节,具备一定的Common Sense,紧贴前沿技术方向。当团队出现困境的时候,挺身而出帮助团队找到方向,走出困境。正因为如此,技术Leader在技术上所花的时间也是最多的,将近50%的时间需要投入在技术上。

 

 
1、技术规划

 

没有规划的团队,如行夜路,走到哪里算哪里。作为业务交付方完成工作,或是领导下发工作的二传手,纯粹通过一些管理手段和管理工具对团队进行管理,对团队没有任何帮助,反而造成伤害(缺乏主动性,得过且过)。

 

技术Leader需要结合公司主业及经营目标和策略,对未来短到1年,长到3、5年支撑业务的发展和转型所需的技术进行规划和储备,发掘新的技术方向以及演进路径,制定相关技术规范,执行过程中进行架构治理,为业务达成目标提供工程、数据和AI技术上的支持和赋能,并在实际的工程实践中进行纠偏。最终,整体的系统水平能够拉开和同行同业的差距。

 

 
2、基础设施

 

有一定基础的研发团队都有其技术偏好,需要针对相关技术栈补齐技术中台(如微服务的注册中心、配置中心以及服务治理等平台),建设自动化工具(如自动化测试、自动化运维工具平台等),保障研发、测试、运维、安全等多个角色能协同高效配合工作。

 

基础技术团队通过技术提升研发团队的自动化、智能化能力,让业务研发团队告别原始的刀耕火种生产模式,通过通晒、检视、评审等多种方式,业务研发团队从平台和工具中获取能力,也为基础技术团队提供具体的场景和反馈。

 

 
3、平台建设

 

基于集中共享建设的模式,在共享层面沉淀出业务中台、数据中台、共享服务以及组件等平台和服务,在团队内统一拉通建设,避免造成系统烟囱,重复建设造成浪费资源。

 

 
4、研发效能

 

人均产值、产能、代码行等衡量团队的产能的指标。对指标进行下钻,反映出的是研发团队中产品、开发、测试、运维等各个角色协作的顺畅程度,其各个部门、各个团队之间墙的厚度,整个团队要跑得快、跑得稳,找出影响研发各环节的关键因素,重塑研发过程,提升研发体验。

 

二、业务Sense

 

技术是依赖于业务而生的,抛开业务谈技术就是耍流氓,纯粹的技术是没有意义的。作为一个技术人,听到这句话虽然觉得刺耳,但确实时刻提醒技术Leader应避免纯粹“技术自嗨”去追求系统或架构的先进性和最优解,避免最终技术方案因没有合适的应用场景成为“烂尾工程”。

 

技术Leader应基于业务场景,设计有一定前瞻性的技术方案,高效地解决业务问题,控制技术成本,为业务高速发展提供技术支撑,赋能业务。相较于技术上的投入,30%的时间要投入在业务上,帮助研发团队做好交付和赋能。

 

 
1、业务交付

 

抛开业务谈技术是没有价值的,技术首先是服务业务,为业务的需求提供交付而存在。所以,不要瞧不上“交付”二字,这是技术团队存在的基础。

 

 
2、技术赋能

 

在做好交付的基础上,技术作为一个成本部门,特别是属于业务部门中的技术团队,赋能业务,对业务进行提质降本增效,是其存在的附加价值。通过MVP产品进行敏捷迭代的方式,技术与业务互为补充,相互促进,共同服务于公司的经营。

 

三、管理能力

 

技术Leader在技术基础,对业务赋能的基础上,最终才是团队管理,包括对人、事、钱的管理。也包括向上管理,对齐领导对技术团队的方向性要求,同时为团队争取到必要的资源。向下沟通,深入一线,切合实际解决一线实际的困难和问题。

 

 
1、人

 

团队重要的是人,对人才盘点,按照用人标准,进行选用育留,穿透式管理,建设一个成长型组织,保证团队高效的执行力。同时注重团队建设,带领团队趟过荆棘,拿到结果,这里的结果不仅是考核结果,还包括不好量化的个人成就感,团队技术氛围提升,团队成员成长等结果。

 

 
2、事

 

要结果,更要关注过程。KPI是一个好东西,可以量化工作的产出,但是唯KPI论,遇到问题就为团队定一个KPI,这种涸泽而渔的做法,短期看是拿到了结果,长期整个团队为了拼凑KPI数字挖空心思,结果是大家都挑容易的工作做,而一些具有里程碑意义、难度也较大的工作却无人问津,KPI越来越多,业务价值越来越低。

 

“我不管过程,只给我结果”这类的沟通,大家权且当做一个行外人的谈资。所以,结果只应该是所有过程努力的一个附属品。更应该珍视执行过程中客观暴露出的问题,通过建标准、定流程等方式建章立制,帮助团队打胜仗拿到结果。

 

 
3、钱

 

管好钱,对预算进行管控,定期检视审计。团队资源不可能无限膨胀,所有的架构设计、技术方案、团队规模等都是在合理的投产范围内,资源该投向哪些重点项目,向哪些团队倾斜,应该建立在一定的ROI基础上,向价值高、投产适度的项目聚焦。

 

>>>>

参考资料

 

  • 从工程师到技术leader的思维升级

    https://mp.weixin.qq.com/s?__biz=Mzg4NTczNzg2OA==&mid=2247483869&idx=1&sn=0edcb5c5a573a9cbd24207a3017edd69&scene=21#wechat_redirect

     

 

作者丨kevin
来源丨公众号:布丁笔记(ID:bdnotes)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告