技术领导力实战笔记
TGO鲲鹏会
100位CTO的真知灼见
立即订阅
14777 人已学习
课程目录
已完结 268 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 卓越的团队,必然有一个卓越的领导者
免费
第1讲 | 你的能力模型决定你的职位
第2讲 | 七位CTO纵论技术领导者核心能力
第3讲 | CEO实话实说:我需要这样的CTO
第4讲 | 技术领导者不等于技术管理者
大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀
第5讲 | CTO的三重境界
第6讲 | 像CEO一样思考
第7讲 | 要制定技术战略,先看清局面
第8讲 | 技术领导力就是“成事”的能力
大咖对话 | 未来技术负责人与首席增长官将如何协作?
第9讲 | CTO是商业思维和技术思维交汇的那个点
第10讲 | 创业公司CTO的认知升级
第11讲 | 最合适的技术才是最有价值的技术
第12讲 | 谈谈CTO在商业战略中的定位
大咖问答 | 打造自己的个人品牌,你也可以
第13讲 | 把脉高效执行的关键要素
第14讲 | 从零开始搭建轻量级研发团队
第15讲 | 定制高效研发流程
第16讲 | 培养中层团队的管理认知
大咖问答 | 发现下一个小米,不是只能靠运气
第17讲 | 团队成长要靠技巧和体系
第18讲 | 做到这四点,团队必定飞速成长
第19讲 | 将企业打造成一所终身大学
第20讲 | 论团队管理与共同升级
大咖对话 | 技术人真正需要的是升维思考
第21讲 | 绩效管理的目标不仅仅是绩效考核
第22讲 | 验证研发团队价值的绩效考核机制
第23讲 | 产品技术团队OKR使用法则
第24讲 | 996、987,程序员加班文化你怎么看?
大咖对话 | 技术管理者应该向优秀的体育教练学习
第25讲 | 建立有效的员工淘汰机制
第26讲 | 让细节的“病毒”感染你的团队
第27讲 | 如何在不同组织文化下推行技术管理
第28讲 | 业务高速增长期的团队管理:“知轻重、重绸缪、调缓急”
大咖对话 | 让团队成员持续的enjoy
第29讲 | 被80%的人误解的工程师文化
第30讲 | 关于工程师文化的六个问题
第31讲 | 五位技术领导者的文化构建实战
第32讲 | 文化是管理的那只无形之手
大咖对话 | 创业就是把自己过去的经验快速的产品化
第33讲 | 选对的人,做正确的事情
第34讲 | 打好技术团队搭建的基础
第35讲 | 做个合格的技术岗位面试官
第36讲 | “高潜力人才”的内部培养
大咖对话 | 如何高效管理8000+规模的技术团队
第37讲 | 技术创业该如何选择赛道
第38讲 | CTO要掌握的产品哲学:理性与人性的权衡
第39讲 | 从客户价值谈技术创新
第40讲 | 技术人投身创业公司之前,应当考虑些什么?
大咖对话 | 技术人创业前衡量自我的3P3C模型
第41讲 | 技术人创业前要问自己的六个问题
第42讲 | 团队激励之分配好你的奖金
第43讲 | 通过积分考核提升技术团队的绩效
第44讲 | 空降技术高管的“择业七计”
大咖对话 | 如何打造自我驱动型的技术团队?
第45讲 | 选好人生下一站——CTO空降上篇
第46讲 | 走出“至暗时刻”——CTO空降下篇
第47讲 | 空降领导者平稳落地要做的四道题(上)
第48讲 | 空降领导者平稳落地要做的四道题(下)
大咖对话 | 管理者是首席铲屎官?
第49讲 | 打造高效的研发组织架构:高效研发流程那些事(一)
第50讲 | 你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)
第51讲 | 聊聊研发流程管理中的那些坑:高效研发流程那些事(三)
第52讲 | 数据如何驱动研发高效运转?谈高效研发流程那些事(四)
大咖对话 | 对人才的长期投资是人才体系打造的根本
第53讲 | 如何打造高效且敏捷的组织文化?谈高效研发流程那些亊(五)
第54讲 | 打造高速运转的迭代机器:现代研发流程体系打造(一)
第55讲 | 用机器打造迭代机器:现代研发流程体系打造(二)
第56讲 | 有了敏捷开发,那交付期限去哪儿了?
大咖对话 | 项目成功的秘诀——技术产品双头负责制
第57讲 | 敏捷中的期限之殇,软件业该怎么做?
第58讲 | 如何打造个人技术品牌?
第59讲 | 技术演讲,有章可循
第60讲 | 正确对待技术演讲中的失误
大咖对话 | 不可替代的Java:生态与程序员是两道护城河
第61讲 | 刘俊强:技术最高决策者应该关注技术细节吗?
第62讲 | 张溪梦:技术领袖需要具备的商业价值思维
第63讲 | 未来组织形态带来的领导力挑战
第64讲 | 如何判断业务价值的高低
大咖对话 | 池建强:做产品不要执着于打造爆款
第65讲 | 如何打造高效的分布式团队?
第66讲 | 如何打造有活力、持续创新的研发团队?
第67讲 | 如何打造独属自己的工程师文化?
第68讲 | 如何打造一个自组织团队?
大咖对话 | 童剑:用合伙人管理结构打造完美团队
第69讲 | 茹炳晟:QE团队向工程效能团队转型的实践之路
第70讲 | 王昊:技术、产品、管理的不同视角
第71讲 | 王昊:什么样的人适合考虑管理角色
第72讲 | 创业公司如何招到合适的人才
大咖对话 | 以产生价值判断工程师贡献——读者留言精选
第73讲 | 用数据来分析管理员工
第74讲 | 为什么给了高工资,依然留不住核心员工?
第75讲 | 刘俊强:一本正经教你如何毁掉一场技术演讲
第76讲 | 内部技术会议的价值
大咖对话 | 韩军:CTO转型CEO如何转变思路
第77讲 | 陈晨:谈谈Instagram文化和文化背后的故事
第78讲 | 陈晨:团队重组过程中踩过的坑
第79讲 | 程军:从0到1打造高效技术团队的方法论
第80讲 | 马晋:技术Leader的持续成长
技术领导力实战笔记
登录|注册

第34讲 | 打好技术团队搭建的基础

前中恒云能源CTO,TGO会员吴万港 2018-06-12
从运营、到产品、再到技术研发落地,都需要一个团队的执行,尤其要仰仗团队的核心骨干来执行落地。对于 CTO 等技术领导者来说,招聘始终是绕不过去的话题,毕竟,任何一个团队,都不是每个岗位都齐整,等着你来领导的。如果技术领导者不能搭建自己的强大团队,是无法胜任其岗位的。
那么,招聘前需要做好哪些准备工作?如何定岗定级?有哪些有效的招聘渠道?本文将就这些问题展开探讨。

明确发展阶段

首先要明确的是公司发展阶段,这点非常重要。产品从 0 到 1,和 1 到 N 的过程中,对团队的人员需求,能力诉求是完全不一样的。在从 0 到 1 的过程里,讲究的是如何高效的利用现有的条件实现产品研发落地,而不过分追求技术的先进性。
这个阶段中,往往从 CEO 开始到一线的产品、研发人员未必清楚产品在市场上的响应,整个团队的核心思想其实是需要将产品放到市场上试错,从而收集第一手的用户数据,这时,时间决定一切。这个时候的 CTO(未必就是一个 CTO,可能是技术总监或者技术专家的角色)更多应该扮演的是技术专家的角色,主要的工作是根据产品的设计,带领大家一起写代码,并在团队资源紧张的情况下,自己撸起袖子写代码。
随着产品在市场的反响越来越好,慢慢的有了一些用户基础和用户数据,数据日益增长,原来的系统架构越来越不能胜任用户增长、数据增长的需求,要求平台从会员、商品、WMS、交易等进行划分,甚至微服务化,此时对团队的技术能力要求也越来越高,需要专人专岗负责,甚至专业的团队来负责。这时,团队规模较公司创立之初有了较大幅度的扩张,CTO 应该将更多的精力转移到团队管理,如绩效、战略等。
明确团队发展阶段对于 CTO 来说,是招聘的前提,比如在创业之初,没有 P9 级别的诉求。做技术的人都有一个通病,总是希望将技术做到极致。殊不知,在 QPS 1000 都到不了的情况下,从技术上将 QPS 做到 100 万级别没有任何价值。
在本人的从业经历中,遇到过这样的例子:当时公司 TPS 大概在 100 左右,本人空降过去成为技术 Learder,团队里有一个技术控,他的技术能力确实不错,一眼就能看穿我们当时的系统技术上的瓶颈。但是当时的系统足够使用,没有从技术上改造的必要。而当时另外的一个业务产品需要新的团队来负责,我希望由他来负责,但是他就是不想负责这个业务产品,就是想对平台的技术进行改造,希望团队能协调资源支持他进行改造。多次沟通无果,最后不欢而散。
我也遇到过另外一个相反的例子,当时我们系统的 TPS 大概在 3000 左右,而实际的用户场景中对 TPS 的需求已经达到了 30000+,直接导致系统每天都要不定时的重启。我认为每天对生产系统不定时的重启是不合理的,而且没有监控系统,不知道什么时候需要重启。在本人未入职之前,整个技术团队为了解决这个问题,将所有的精力都投入到了新产品的研发中,而置生产系统不顾,关键是新的产品不知何时落地何时上线,也不知能否解决这个问题。我上任之后的第一件工作就是希望解决这个问题,其实从技术上来说并不难,但由于团队里没有合适的人,只能是我自己带领技术人员来解决。
以上例子说明,作为技术领导者,在用人和招人时,要非常明确团队所处的阶段,在合适的阶段用合适的人,当然也包括 CTO 在内。

定岗定级

大多数的创业型互联网公司都是靠融资活着,在公司扩张方面,有人任性,有人谨慎。当然也见过有人任性到拿到投资时无限制招人,到最后裁员的结局。任何一家公司都不可能无限制的扩张,基本都是根据业务的需求制定合理的招聘需求,对于技术领导者来说也是一样的。
作为一个技术领导者,需要根据业务和产品的需求,结合现有团队的资源(现有团队的能力分布对于新的业务需求在招聘岗位上的能力需求是很有意义的参考),定义岗位的能力要求。
比如,现在要做一个 WMS,那么首先就要评估团队的现状,明确团队的技术栈(比较忌讳采用全新的技术栈,一般沿用现有的技术栈)。从产品角度来说,如果团队成员对 WMS 都比较熟悉,但就是没有资源能将想法落地,此时需要一个对 WMS 有点概念或者比较资深的产品经理来设计落地即可,至于招聘还是内部提拔,视不同情况而定。
对于研发技术人员的需求,本人比较崇尚根据目前团队某个产品的 duty team 的构成作为参考,而不是盲目地提升团队的需求,导致招人困难,致使项目延期;也不需要为了便于招人,刻意降低团队的需求,从而导致最后产品质量没法保障。
那么如何定级呢?相信大家对现在互联网行业中的 P/M 定义都非常熟悉,但是不能照搬,要结合自己团队的现状定义合理的级别。此时,HRBP 在这个过程中能够起到很大的作用,通常 HRBP 在每个季度都会对团队的效能进行分析,明确每个团队,每个伙伴的绩效分析,和效能分析报告。CTO 可以根据这些分析报告,结合业务需求,制定比较合理的 headcount。
在技术管理者中不乏这样的人,对 headcount 的诉求是拍脑袋决定的,总觉得人越多越能显示权威,说明自己越厉害。这样的技术管理者自身就是不合格的,我们一定要避免陷入这种思维。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术领导力实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(2)

  • 米斯特.杜
    明确发展阶段是很关键的一步。决定了团队怎么走。我们团队组件快两年了,但因为业务起色不大,还在不断试错,感觉还是0到1阶段。
    2018-06-13
    1
  • David Mao
    讲的很有道理。企业发展的不同阶段对人才的诉求是不同的,即从0到1 和从1到n 是完全不同的诉求。
    2018-11-24
收起评论
2
返回
顶部