为什么 CTO、技术总监、架构师都不写代码还这么厉害?

2023-03-19 02:01:01
'CTO/技术总监、架构师大部分都是码农出身,极少数除外(比如曾经的阿里 CTO王坚),你非让他们写代码肯定没问题,但一个组织的领导者只以写代码来要求,并认为不写代码就不厉害那也太过狭隘了。关于 CTO/技术总监之类的技术管理者要不要写代码曾经在互联网掀起了狂风巨浪般的争吵,说实话大多是外行在看热闹,内行其实都懂那些门道。就拿CTO来说,真正重要的工作是:把握公司技术战略、激活公司技术组织、探索前'

我是技术总监,所谓的CTO,现在除了看论文这个和技术直接相关的习惯外,其他的具体开发工作都不做了。一行代码也不写了、一个实验也不做了、一台设备也不调试了。现在的主要工作是保证产品持续具有竞争力和培养队伍。

之前写过类似的一个回答,收到一些知友的好评,再次感谢曹老师( @曹力科 )邀请。我打算再次认真的回答一下这个问题。来说说公司里CTO为什么不做具体的事情,包括这个逻辑是怎么演化过来的,以及它的合理性和必要性。

故事还得从我们团队创业那天开始说起。

一. 创业初期

我们公司做的是测试仪器。创业初期,我是那个亲手做东西的人,全面负责,从理论到实现,从加工到调试,什么要做做什么,什么不会学什么。第一代原型机就是在我手上诞生的。那时候要做的事情很具体,问题也很多,但是我非常兴奋,每天睡4-6个小时,不用闹钟,是兴奋醒的。

我既是技术副总,又是技术总监,又是部门主管,又是一线员工。

二. 小团队

后来,招了几个人,就有了分工。

  1. 我给结构工程师讲了我的想法,让他去实现,他画好了给我看,我定稿。
  2. 告诉电路工程师仪器原理,让他改进我的电路,我帮他把关。
  3. 告诉软件工程师我想要什么样的功能,我设计构架,他来写软件。
  4. 告诉算法工程师我想实现什么效果,他实现了之后问我是不是这样的。
  5. 告诉调试工程师如何去调试,因为我最懂原理。
  6. 告诉应用工程师客户的需求,让他去尝试方法。

这个阶段,面临的是切割工作接口、协调分工合作、解决工作之间的冲突。

我的做法是民主集中,讨论畅所欲言,结束我来拍板。

这个阶段,一些工程师总是喜欢在我的设计上挑毛病。当然,只要他是想着把事情做好,这个我是包容的,就怕有的二逼在那里砸锅。记得有个FPGA工程师,我给他讲思路,他从一开始就怀着一种挑战对抗心理,以找我的毛病为工作目标。甚至在私下说我不懂瞎指挥。好,砸锅?那显然不是我们队伍里的人,我们之间无缘,你去挑战下一任雇主吧。

总之,那个阶段,我带领他们去完成我大脑中勾勒的那个蓝图。革命尚未成功,同志们去完成我所没有完成的那部分工作。

这样。第一代研发样机就做出来了。样机比原型机要好很多了,既稳定又漂亮,毕竟是专业的人做的专业的事。

这个阶段,我既是技术副总,又是技术总监,又是部门主管。参与和指导一线工作,但是不再负责一线工作,我褪掉了「一线员工」这个角色。

我的工作理念开始从管好自己向管好他人转变。主要工作就是想好做什么、做好规划、带领大家奔着一个目标努力。当然少不了还是要在一线指导。

这个阶段我睡的更少,既要靠激情、责任,还要靠闹钟。

三. 分级

再后来,队伍又大起来了,有了20多个人。

基本上每个岗位有几个人了。

这个时候的研发工作基于样机了,我亲手做的那台丑陋的原型机已经被放到了展厅。经过第二阶段,熟悉样机的人已经有好几个人了,而我却不能熟悉到每个细节,我把那些有组织能力而且技术水平较高的人提拔为部门主管。

这个时候,我不再去参与每一个细节(太多了顾不过来),基本上就是开会和追进度,不去一线战斗了。只有遇到原理的问题,部门主管才来找我探讨技术问题,找我支招。

我既是技术副总,又技术总监。我又褪掉了「部门主管」的角色。

我这个阶段的工作理念就是物色合适的人来做部门主管,我和他们一起来设计产品,做工作计划,监督实施。

我选拔的人越优秀,我参与具体研发工作就越少。我的计划定的越合理,大家工作的越和谐。

这个时候结构工程师说结构是他设计的,电路工程师说电路是他开发的,软件工程师说软件是他写的,算法工程师说算法是她研究的,调试工程师发现也有很多我解决不了的问题需要他们自己去琢磨……新来的员工感觉,他们的部门主管和老员工比我厉害多了,我对样机都不如他们主管熟悉。他们除了觉得职务上我比他们高外,其他的我啥都不行。甚至在他们眼里,这台仪器的研制我作为技术老大什么都没做。面对这种想法,我很开心,说明我选的主管很优秀,我留下的员工很能干。

在部门主管们的努力下,α版本的仪器出来了!我开始组建测试团队和生产团队,沟通市场团队去做客户试用,和生产团队对接试产。

这个阶段我睡觉更少了,因为要想的事情很多,我的考虑不合适会累死三军,每一步都如履薄冰,我不得不买了厚厚的一摞书,学习科学的管理方法。经常我睡到半夜就醒了,起来点上一根烟,接着工作。

四. 保证流程运转,物色优质人才,做甩手掌柜

经过α版本的试用迭代,产品完善很快,队伍进步也很快,转产流程也走通了,整个工作流程可以完整的运行。

就这样,β版本产品很快出炉!

面对这台仪器,我已经不能像了解我的手一样了解它了。员工们都认为这台仪器不是我做的,是大家集体智慧的结晶。当我感到大家有这种想法的时候,我很高兴,说明大家参与感很强,团队很凝聚。

我物色了一个非常靠谱,而且很机灵的员工,让他做了测试部门的主管。仪器能不能过关,我只问他,他只对我负责。这样我对产品的品质也不用自己亲自去把关了。

我依然担任着技术副总,兼任技术总监的工作,工作理念已经基本转换到管人。等到物色到合适的人,时机合适的时候我再褪去技术总监的角色。

现在,我的工作就是和总经理开会制订年度计划,和产品经理们开会对接需求,和部门主管开会制订工作计划、听汇报,和人事部门主管一起物色优秀人才。顺带作为公司技术负责人带带实习生,在适当的时候给大家鼓鼓劲。

只要工作流程能顺利运转,所有的开发工作都像水一样在各部门流动,最终流出来就是合格的产品。我协调各方保证流通的顺畅,就可以下班回家休息了。

实际上是可以这样的,但是我没有。我还在加班加点,很多时候是看书和想事情,完全是爱好和个人的工作态度。

我越来越多的在想如何能让这个流程更有效、更简洁、更顺畅,还要思考如何让团队更有战斗力,那就是选对合适的人到合适的岗位。

研发工作,好像工程师们普遍觉得我根本就没干,我已然成为公司中可有可无的那个人。无所谓,评价我的不是员工,而是总经理和董事会。

五. 科学化、新挑战

上面是我野路子方式完成从0到1的CTO成长之路,整个过程不是从顶层设计开始的。

通过学习、实践和思考,现在我已经能够从顶层设计去实现一个团队的组建和管理。

于是,去年我受邀加入一家新的初创公司,出任总经理,自己又是0号员工。

从公司成立,我就开始组建团队,采用IPD研发管理模式。新公司,我一开始好像就没有做具体的研发工作,很多新同事认为我什么都不会,就会制定规则、开会和评审,然后就是写写文档、看看手机,以及喝茶和抽烟。


~~~~~~2023年3月22日 01:50追更~~~~~~

  1. 知友 @赵晓白 说这篇文章他看过不止两遍,是不是我写的。我确认一下,都是我写的,可能被转到了其他地方。最原始的原文在这里:

2. 回复知友幻影的问题。不好意思@不到你,不知道是不是回复晚了你把我拉黑了。(手动捂脸)主要是周一周二公司开会、项目开会,加上接待了两个基金调研,所以回复晚了,非常抱歉。

,

CTO/技术总监、架构师大部分都是码农出身,极少数除外(比如曾经的阿里 CTO王坚),你非让他们写代码肯定没问题,但一个组织的领导者只以写代码来要求,并认为不写代码就不厉害那也太过狭隘了。

关于 CTO/技术总监之类的技术管理者要不要写代码曾经在互联网掀起了狂风巨浪般的争吵,说实话大多是外行在看热闹,内行其实都懂那些门道。

就拿CTO来说,真正重要的工作是:把握公司技术战略、激活公司技术组织、探索前沿技术应用等等,重点其实是围绕公司商业来制定技术战略,并实施技术战略。这里面需要的更多是商业sense和领导力。

你非拿一个CTO和一个高级工程师比业务代码编写速度,那还真有可能后者胜出,但后者肯定是担任不了CTO的,而CTO大概率曾经是一个高级工程师。

我前两年先后在两家独角兽公司做过CTO,积累了一些经验和教训,并且身边有大量的创业公司CTO朋友,经常和他们交流,甚至我还弄了一个创业公司CTO俱乐部:

基本上北京知名创业公司的CTO都在这个群里,IT届的扛把子左耳朵耗子叔也在。

而在今天IT行业高速发展的现状下,很多技术大牛就因为技术特别牛逼,可能就会被提拔成技术总监甚至CTO。

能否做出好的技术选型节约团队研发时间?能否管理好老板不合理的预期?能否整合公司其他部门资源为本部门所用?能否把本部门的价值输出最大化?能否给部门产品技术赋能,形成对竞争对手的技术竞争优势?

这些才是管理上百人甚至几百人的CTO/技术总监需要重点思考的事情。真正硬核的技术大牛,可能更适合单干或者带一只特种部队(10人以内),因为他们的价值更多在于技术攻坚而非技术领导力。

我认为:每一位真正的CTO/技术总监,都需要具备超强的技术领导力,都需要跨越的四道槛:

1.第一个跃升,叫责任跃升

CTO的主要职责是:

平台规范:与技术经理/架构师/程序员共建软件公共平台
提升效率:提升技术团队的工作效率,构建技术团队的文化
资源协调:管理和协调公司各个部门占用本部门各条线的资源
教练技术经理/架构师,提升技术经理的管理能力,提升架构师的业务思维
参与商业决策
确定对竞争对手的技术优势

我刚担任一家A轮公司CTO时,团队遇到技术困难,习惯于上阵去解决。问题是解决了,回头发现团队的产出反而慢了。原因很简单,关键的技术决策、规划、资源协调、培养下属、商业决策等工作都被耽误了。

CTO/技术总监需要对技术团队业绩负责。当团队规模变大,除非问题真的只有你能解决,否则不能轻易陷进去。承担新的责任,很重要。

(PS:感谢大家耐心阅读,顺便给大家推荐一份阿里P8大佬撰写的算法笔记,程序员要想进大厂先从刷算法做起是个好方法,算法厉害的人进大厂非常容易,身边不少朋友通过它加入大厂:

看看这本书的目录和排版!相当经典!


2.第二个跃升,叫业务跃升。

要实现这种跃升,先做到四个理解:

从用户价值视角去理解业务:业务必须为用户价值服务,需要洞察用户真正需求。

从用户视角去理解业务:用户从哪来,整个流转过程做了哪些事、用户使用业务的具体场景是什么?

从商业视角去理解业务:业务方向跟公司的商业战略是否一致,怎么通过业务流程赋能商业腾飞?是降本增效还是增大投入取得突破?

从产品视角去理解业务:产品怎么完成对业务的支撑?开发哪些产品重要,哪些没那么重要?

这四个理解,又可以称为:业务洞察力

CTO需要提升对用户的理解、具备基础的商业知识和一定的产品能力。并将这些能力应用到对业务的驱动中,最终培养出卓越的业务洞察力。

这就是第二个重要的跃升:业务跃升。

另外我把大学和工作中用的经典电子书库(包含数据结构、操作系统、C++/C、网络经典、前端编程经典、Java相关、程序员认知、职场发展)、面试找工作的资料汇总都打包放在这了,点击直接获取:

我已经帮大家打包好了,点击下方链接直接获取:



看看这本书的目录,非常经典:

3.第三个跃升,叫战略跃升

CTO必须具备一定的战略决策能力。什么是战略决策能力?战略决策能力不是有很多天才Idea,每个Idea都可以颠覆世界。比决定做什么更重要的是你能决定不做什么。

只有真正理解了用户、业务、商业、产品,才能做出最重要的关键决策。进而才能具备战略决策能力。技术团队是成本团队,资源用在哪,资源投入的多少,都需要决策。

拿阿里举例:阿里要求P9管理者要具备一年的战略决策能力,P10要具备三年的战略决策能力。

能不能在有限资源下,做出正确的选择,这是做好技术总监的第三个重要的跃升:战略跃升。

4.第四个跃升,叫沟通跃升

既然是CTO,自然需要跨部门协调资源、推进合作、判断需求,有时候可能还要做跨公司的沟通。这个过程,真正理解其他部门/公司的需求非常重要。

有时候,技术人和其他部门的同事会有沟通困难的感觉,甚至相互都觉得对方不能理解自己,其实往往是沟通语言上出了问题。

对CTO而言更困难的是如何跟老板沟通。前几天,和几个做安全的技术VP聊天,大家谈到一个问题:企业的安全投入力度怎么控制。

一个朋友说了这么一段话:安全防护这件事很头疼,不出事老板觉得团队没什么价值,出事了老板也会觉得团队没什么价值。其实不仅是安全团队,只要是技术支撑型团队,遇见不是技术出身的CEO,都有可能存在这种困境。

大家讨论了半天,最后结论是:这必须有一个能向上做好管理的CTO。他需要能用老板听得懂的语言,告知投入的必要性,并获得老板的支持。

CTO如果不能做到和老板的良好沟通,结局一般都会暗淡出局。

以上四点是我认为CTO需要具备的能力。

CTO和总监还需要三点基本能力:

1.以身作则

这点是管理中最重要的一点,没有之一!

很多人天真的以为管理者就是管团队,管别人,别提多滋润。错!一名真正优秀的管理者首先是管理自己,并且在工作中能做到以身作则!先来看张图:

请问大家喜欢哪一种管理者?我认为优秀的管理者绝不是高高在上的BOSS,而是带着使命感带领大家走向团队成长的那个人。

你的一言一行、一举一动对员工都具有教育性、示范性和影响力,起着耳濡目染、潜移默化的作用。

很简单,你要求团队不准迟到,那你自己就别迟到。你想让团队打鸡血奋勇杀敌,那你也要冲在前面,不是兄弟们天天加班你天天度假。

还要说一句:以身作则是传递企业价值观的唯一方法!

2.提升领导技能

领导技能缺失是很多业务骨干被提升为初级管理者后的最大障碍,甚至很多人在整个管理生涯中,都无法在领导技能这一项里取得突破。

一个业务骨干,如果沟通还不错,很容易在团队被提拔成经理。而这个时候角色就从个人贡献者跨越到团队贡献者。所考虑的首先是团队的效能,而不是个人的贡献。

领导技能的跨越:

  • 总监级别需要实现从管理他人到管理经理人员的跨越,这一层级管理者要开始具备更广阔的视野,要对业务有更深入的理解,并且要肩负培养和教练一线经理的职责
  • 高级总监/事业部总经理需要实现从管理经理人员到管理职能部门的跨越,这一层级的管理者要开始关注商业/业务/财务,并培养制定长期战略的能力
  • VP/CXO需要拥有优秀跨部门沟通整合能力,优秀的战略洞察能力以及对商业/业务/财务的深度理解

管理者共同的领导技能包括:

  • 充分的授权和关键节点的检查
  • 能担任下属的职业教练
  • 制定团队计划的能力
  • 目标管理的能力
  • 优秀的沟通协调能力

千万千万千万千万千万千万不要出现管理错位!

比如经理干着骨干的活,天天攻坚,让骨干没活可干。总监直接管着所有人,让经理没法成长。VP带着一群经理,让总监无所适从。

3.学会时间管理

新的时间分配结构,决定如何工作。

先说一句:如果没有培养出对应管理层级需要的领导技能,那这个管理者的时间分配一定会有严重问题。

管理层级的时间分配:

  • 总监级别需要将大部分时间用于管理、沟通、协调资源,同时需要花时间深度理解业务,并且要开始学习更多新知识
  • 高级总监/事业部总经理需要花更多的时间分析、思考、平衡长期目标和短期目标,并要开始具备一定的战略规划能力
  • VP/CXO需要花大量时间和事业部班子成员沟通,花大量时间学习新领域,规划新业务,参与制定公司战略

每个程序员其实都有一个技术总监/CTO梦想,这里再送一本我撰写的技术人职场发展资料:

祝大家前程似锦,在编码的道路上一马平川。

要是觉得不错的话,那就帮我

@findyi

点个赞,一键三连呗,硬核码字不易。

'
'

CTO/技术总监、架构师大部分都是码农出身,极少数除外(比如曾经的阿里 CTO王坚),你非让他们写代码肯定没问题,但一个组织的领导者只以写代码来要求,并认为不写代码就不厉害那也太过狭隘了。

关于 CTO/技术总监之类的技术管理者要不要写代码曾经在互联网掀起了狂风巨浪般的争吵,说实话大多是外行在看热闹,内行其实都懂那些门道。

就拿CTO来说,真正重要的工作是:把握公司技术战略、激活公司技术组织、探索前沿技术应用等等,重点其实是围绕公司商业来制定技术战略,并实施技术战略。这里面需要的更多是商业sense和领导力。

你非拿一个CTO和一个高级工程师比业务代码编写速度,那还真有可能后者胜出,但后者肯定是担任不了CTO的,而CTO大概率曾经是一个高级工程师。

我前两年先后在两家独角兽公司做过CTO,积累了一些经验和教训,并且身边有大量的创业公司CTO朋友,经常和他们交流,甚至我还弄了一个创业公司CTO俱乐部:

基本上北京知名创业公司的CTO都在这个群里,IT届的扛把子左耳朵耗子叔也在。

而在今天IT行业高速发展的现状下,很多技术大牛就因为技术特别牛逼,可能就会被提拔成技术总监甚至CTO。

能否做出好的技术选型节约团队研发时间?能否管理好老板不合理的预期?能否整合公司其他部门资源为本部门所用?能否把本部门的价值输出最大化?能否给部门产品技术赋能,形成对竞争对手的技术竞争优势?

这些才是管理上百人甚至几百人的CTO/技术总监需要重点思考的事情。真正硬核的技术大牛,可能更适合单干或者带一只特种部队(10人以内),因为他们的价值更多在于技术攻坚而非技术领导力。

我认为:每一位真正的CTO/技术总监,都需要具备超强的技术领导力,都需要跨越的四道槛:

1.第一个跃升,叫责任跃升

CTO的主要职责是:

平台规范:与技术经理/架构师/程序员共建软件公共平台
提升效率:提升技术团队的工作效率,构建技术团队的文化
资源协调:管理和协调公司各个部门占用本部门各条线的资源
教练技术经理/架构师,提升技术经理的管理能力,提升架构师的业务思维
参与商业决策
确定对竞争对手的技术优势

我刚担任一家A轮公司CTO时,团队遇到技术困难,习惯于上阵去解决。问题是解决了,回头发现团队的产出反而慢了。原因很简单,关键的技术决策、规划、资源协调、培养下属、商业决策等工作都被耽误了。

CTO/技术总监需要对技术团队业绩负责。当团队规模变大,除非问题真的只有你能解决,否则不能轻易陷进去。承担新的责任,很重要。

(PS:感谢大家耐心阅读,顺便给大家推荐一份阿里P8大佬撰写的算法笔记,程序员要想进大厂先从刷算法做起是个好方法,算法厉害的人进大厂非常容易,身边不少朋友通过它加入大厂:

看看这本书的目录和排版!相当经典!


2.第二个跃升,叫业务跃升。

要实现这种跃升,先做到四个理解:

从用户价值视角去理解业务:业务必须为用户价值服务,需要洞察用户真正需求。

从用户视角去理解业务:用户从哪来,整个流转过程做了哪些事、用户使用业务的具体场景是什么?

从商业视角去理解业务:业务方向跟公司的商业战略是否一致,怎么通过业务流程赋能商业腾飞?是降本增效还是增大投入取得突破?

从产品视角去理解业务:产品怎么完成对业务的支撑?开发哪些产品重要,哪些没那么重要?

这四个理解,又可以称为:业务洞察力

CTO需要提升对用户的理解、具备基础的商业知识和一定的产品能力。并将这些能力应用到对业务的驱动中,最终培养出卓越的业务洞察力。

这就是第二个重要的跃升:业务跃升。

另外我把大学和工作中用的经典电子书库(包含数据结构、操作系统、C++/C、网络经典、前端编程经典、Java相关、程序员认知、职场发展)、面试找工作的资料汇总都打包放在这了,点击直接获取:

我已经帮大家打包好了,点击下方链接直接获取:



看看这本书的目录,非常经典:

3.第三个跃升,叫战略跃升

CTO必须具备一定的战略决策能力。什么是战略决策能力?战略决策能力不是有很多天才Idea,每个Idea都可以颠覆世界。比决定做什么更重要的是你能决定不做什么。

只有真正理解了用户、业务、商业、产品,才能做出最重要的关键决策。进而才能具备战略决策能力。技术团队是成本团队,资源用在哪,资源投入的多少,都需要决策。

拿阿里举例:阿里要求P9管理者要具备一年的战略决策能力,P10要具备三年的战略决策能力。

能不能在有限资源下,做出正确的选择,这是做好技术总监的第三个重要的跃升:战略跃升。

4.第四个跃升,叫沟通跃升

既然是CTO,自然需要跨部门协调资源、推进合作、判断需求,有时候可能还要做跨公司的沟通。这个过程,真正理解其他部门/公司的需求非常重要。

有时候,技术人和其他部门的同事会有沟通困难的感觉,甚至相互都觉得对方不能理解自己,其实往往是沟通语言上出了问题。

对CTO而言更困难的是如何跟老板沟通。前几天,和几个做安全的技术VP聊天,大家谈到一个问题:企业的安全投入力度怎么控制。

一个朋友说了这么一段话:安全防护这件事很头疼,不出事老板觉得团队没什么价值,出事了老板也会觉得团队没什么价值。其实不仅是安全团队,只要是技术支撑型团队,遇见不是技术出身的CEO,都有可能存在这种困境。

大家讨论了半天,最后结论是:这必须有一个能向上做好管理的CTO。他需要能用老板听得懂的语言,告知投入的必要性,并获得老板的支持。

CTO如果不能做到和老板的良好沟通,结局一般都会暗淡出局。

以上四点是我认为CTO需要具备的能力。

CTO和总监还需要三点基本能力:

1.以身作则

这点是管理中最重要的一点,没有之一!

很多人天真的以为管理者就是管团队,管别人,别提多滋润。错!一名真正优秀的管理者首先是管理自己,并且在工作中能做到以身作则!先来看张图:

请问大家喜欢哪一种管理者?我认为优秀的管理者绝不是高高在上的BOSS,而是带着使命感带领大家走向团队成长的那个人。

你的一言一行、一举一动对员工都具有教育性、示范性和影响力,起着耳濡目染、潜移默化的作用。

很简单,你要求团队不准迟到,那你自己就别迟到。你想让团队打鸡血奋勇杀敌,那你也要冲在前面,不是兄弟们天天加班你天天度假。

还要说一句:以身作则是传递企业价值观的唯一方法!

2.提升领导技能

领导技能缺失是很多业务骨干被提升为初级管理者后的最大障碍,甚至很多人在整个管理生涯中,都无法在领导技能这一项里取得突破。

一个业务骨干,如果沟通还不错,很容易在团队被提拔成经理。而这个时候角色就从个人贡献者跨越到团队贡献者。所考虑的首先是团队的效能,而不是个人的贡献。

领导技能的跨越:

  • 总监级别需要实现从管理他人到管理经理人员的跨越,这一层级管理者要开始具备更广阔的视野,要对业务有更深入的理解,并且要肩负培养和教练一线经理的职责
  • 高级总监/事业部总经理需要实现从管理经理人员到管理职能部门的跨越,这一层级的管理者要开始关注商业/业务/财务,并培养制定长期战略的能力
  • VP/CXO需要拥有优秀跨部门沟通整合能力,优秀的战略洞察能力以及对商业/业务/财务的深度理解

管理者共同的领导技能包括:

  • 充分的授权和关键节点的检查
  • 能担任下属的职业教练
  • 制定团队计划的能力
  • 目标管理的能力
  • 优秀的沟通协调能力

千万千万千万千万千万千万不要出现管理错位!

比如经理干着骨干的活,天天攻坚,让骨干没活可干。总监直接管着所有人,让经理没法成长。VP带着一群经理,让总监无所适从。

3.学会时间管理

新的时间分配结构,决定如何工作。

先说一句:如果没有培养出对应管理层级需要的领导技能,那这个管理者的时间分配一定会有严重问题。

管理层级的时间分配:

  • 总监级别需要将大部分时间用于管理、沟通、协调资源,同时需要花时间深度理解业务,并且要开始学习更多新知识
  • 高级总监/事业部总经理需要花更多的时间分析、思考、平衡长期目标和短期目标,并要开始具备一定的战略规划能力
  • VP/CXO需要花大量时间和事业部班子成员沟通,花大量时间学习新领域,规划新业务,参与制定公司战略

每个程序员其实都有一个技术总监/CTO梦想,这里再送一本我撰写的技术人职场发展资料:

祝大家前程似锦,在编码的道路上一马平川。

要是觉得不错的话,那就帮我

@findyi

点个赞,一键三连呗,硬核码字不易。

,

昨天刚和业内TopX的CTO吃饭,有点感想,随便聊聊。

CTO刚进公司的时候,也是写代码的,现在管着一个部门,职责是看公司3-5年的方向。据他说,他自认为能力还不够,Top1的CTO,职责是看公司5-10年的方向。

他的工作时间,70%时间在研究业界的各种技术方向,考虑未来的趋势,结合公司优势,思考公司的战略投入方向;剩下30%工作时间是向CEO汇报,帮CEO向董事会汇报,敲定以及调整公司投入方向和投入资源规模。

他是不可能有时间写代码的,整个部门近百人,都没有时间写代码。公司内和他并行的且有研发队伍的公司副总裁有5个,这些副总裁下面研发人员多则几千,少则几百,也都有一个cto(咱们用小写代替)。这些研发队伍是写代码的,但是cto也没有时间写代码。这几位cto负责落地公司战略,结合产品实际情况进行调整,确定子系统的技术方向,技术架构,也有责任反馈需求和意见,要求公司调整战略。

有几位cto我都很熟,他们其实最怀念的是写代码的时候,心不累,领导说啥就是啥,只管干活就行。现在不一样,一旦技术方向选择错误,不能给公司创造价值,或者成本过高不挣钱,那几百几千的研发人员收入将大幅度下降,这个责任背不起的,心累。

知乎大量程序员,总是瞧不起主管/架构师/cto。说实话,等你到那位置,再说瞧不起的话吧。反正我的头发是从做主管开始迅速白的。

为了避免不必要的麻烦,就不写公司名了。业内的估计能猜出来。而且职位我也没用他们任命的正是职位名,通用称谓代替了吧。

==========20230118更新:==========

评论里有很多朋友觉得技术方向什么的不重要,我正好了解一个早年的例子。

2004年,当时wlan还是比较新的概念,作为很多做数据通信的公司都在为是否开辟这么一条产品线讨论。如果开辟这条产品线,涉及的技术储备,未来市场空间预测,都需要评估。到08年,中国移动全国铺开建设,一个省的采购额都超过2亿,当时某厂商是赚得盆满钵满啊。时至今日,wlan的巨大市场空间已经被多家厂商瓜分,厂商投入进入的先后顺序不同,有的失败有的成功,都是需要决策的。

'