关于CTO该不该写代码：我们调查了100个CTO，70%的人说不用写但要懂

ZD至顶网CIO与应用频道 09月05日 北京消息（文/李超）：近期，某医疗互联网公司前CTO在网络上飙红，很多IT圈人士的微信、微博均遭到刷屏待遇。具体事件经过不再做累述，信息大家都已心照不宣。

我们关心的是，由这次事件所引出的各种声音，其中最突出的一种声音是，广大IT人士开始对CTO要不要自己写代码产生了诸多疑问，大家都各执己见。鉴于此，我们特别设计了一次问卷调查，在本次调查中我们对接近100多名以CTO，CIO为主，也包括程序员、产品开发人员在内的相关人士通过问卷的形式进行了集中调查。并邀请了相关企业的技术人员对调查结果进行了客观评论与分析。以下为本次调查结果：

1．调查人员分布情况

在本次调查中我们对接近100多名包括企业CIO、CTO、程序员、产品开发人员在内的企业在职人员通过问卷调查的形式进行了集中调查。首选，我们姑且把1-50人技术团队的规模定义为中小型业企，在本次调查人员中占了大概1/3的比例；50-200人技术团队我们把其定义为中型企业，在本次调查中占了接近一半的比例。200人以上技术团队的规模我们定义为大型企业，在本次调查中占了1/7的比例。

2．CTO应不应该亲自编写代码

针对CTO应不应该写代码这一热点话题，在我们的调查结果中有比较明显的体现。认为CTO必须写代码的投票占到了大概1/5的比例；认为CTO根本没必要自己代码的人数只占到1/10；而剩下70%多的人则认为，CTO应该懂代码，但不必亲自编写代码。

3．CTO需不需要经常参与日常例会

从结果显示，认为CTO必须每会必开的投票占到了接近一半的比例；认为CTO要尽可能多的参与例会的比例也占到1/3的比例；而认为CTO应该有选择的参加对自己比较重要会议的投票比例占到了1/4；目前，还没有一个人认为CTO是不需要参与日常例会的。

4．CTO在企业中需要履行的职责

对于CTO在企业中都需要履行哪些主要职责的问题，从投票结果显示，按比例从高到低排列依次为：1、团队管理与建设；2、系统架构搭建；3、企业产品与品牌宣传；4、项目协调与监管；5、核心技术攻坚；6、日常技术维护；7其他；

5、CTO在企业中的核心价值

在第五项调查中，我们设置了一道开放性题目，原题目为：结合您的企业，您认为CTO在企业中所应体现出的核心价值是什么？在对这一问题的回答中，我们发现不同行业和规模的企业对CTO所应体现出的价值存在很多差异，以下按照不同企业规模将比较典型的回答列举出来供大家参考。

中小型企业

• 领导技术方向，对于技术团队的成长要给予适当的鼓励和抑制，在团队成长的时候，根据个人经验给予建议，防止技术团队犯下明显的错误。（某粉丝运营平台 CTO）
  
  
• 帮助梳理公司各项业务，使得业务能够标准化，系统化，提升作业效率；帮助企业建立一套强大的系统架构，能够非常灵活的承接各类业务；（某全媒体购物平台 CTO）
  
  
• 技术形象代言人（某教育服务平台 CTO）
  
  
• CTO应该是公司的技术的保证，了解当前的技术潮流。（某科技公司 高级工程师）
  
  
• 技术保证是前提，公司发展是主页（某互联网私厨平台 CTO）
  
  
• 1、IT部门的技术（产品）支持满足公司业务需求；2、部门内外协调管理；3、IT部门整体技术能力得到提升；4、IT部门直接产生经济收入（某企业级垂直门户网站 CTO）
  
  
• 团队的管理，团队成员的培养,帮助技术人员成长。给技术同学创造一个积极向上的学习环境及内部竞争环境。团队是否有成长性和战斗力是CTO的重要考核指标.（某科技公司 CEO）
  
  
• 通过技术节约人工成本；通过技术分析出数据得以优化产品（某互联网私厨平台CEO）

中型企业

• 针对公司业务，规划适合合理的技术架构，并带领团队实现。（某汽车网络媒体 CTO）
  
  
• 团队管理与组织，协调各BU的需求合作，保障公司发展所需的技术支持（某商用车制造商 高级经理）
  
  
• 对公司业务熟悉，对行业技术发展有前瞻性，并能很好利用新技术及架构帮助公司实现效率和营收的提升。（某电子商务企业 CTO）
  
  
• 产品方向（某语音营销平台 CTO）
  
  
• 一、公司战略制定参与，战略实现分解及组织执行； 二、技术选型及系统框架； 三、技术团队组建、职位序列、KPI目标、流程规范； 四、核心业务跨部门沟通，大项目组织实施（某科技门户网站 CTO）
  
  
• 公司技术选型，技术团队创新及人员培养，技术推动公司产品（某摄影门户网站 CTO）
  
  
• 方向方案评估建议。给予业务部门和决策部门更为准确的平台及系统的现状，领会战略方向预估系统瓶颈风险，及时有效的对技术团队予以激励和抚慰。灌输全局观使每一个技术人员了解工作对公司的意义，力求技术团队跟得上公司业务战略思路（某互联网房产平台 高级经理）
  
  
• 站在企业发展的高度上协调技术资源和企业资源（某互联网金融企业 产品总监）
  
  
• 公司战略规划核心人物，公司各方面技术的保障（某互联网房产平台 产品总监）
  
  
• 系统整体方向性把控，核心项目风险把控，技术对业务部门支撑度等（某互联网门户网站 CTO）

大型企业

• 把握技术方向 技术选型（某特卖网站 技术开发工程师）
  
  
• 技术核心，内部更新。技术体系员工福利。（某电商企业 软件开发工程师）
  
  

技术人士评论

• 企业在不同阶段需求不同类型的CTO
  
  

某安全创业企业CTO评论：CTO要不要写代码，需要按企业规模和发展阶段来决定。企业规模越小，CTO要做技术带头人的职能就越明显，甚至可能需要自己去写代码。当公司发展的稍微大点之后，就有些偏重业务了，这个时候公司基本上已经走入正轨，技术已经不是特别大的问题，这时企业做出来的产品是不是用户想要的变成企业很突出的问题，这个时候CTO应该会更关注业务，业务经营怎么样，用户的转化度接受度怎么样之类的问题。而公司发展到更大的时候，CTO就变成了一个“招牌式”人物，更多的是宣传一些概念性的东西，和对一些前沿概念性的研究，甚至可能出去“站台刷脸”，作为象征性的标志。而在这三个阶段企业其实需要不同类型的CTO。所以我们说CTO在这三个阶段可能是三个不同的人，而不是同一个人，在企业的不同阶段需要去做不同的事。

• CTO应该像CEO一样去思考
  
  

某安全创业企业CTO评论：CTO经常是技术出身的，虽然他可能不再做一些底层的编码工作，但是他经常有工程师的那种偏执和只看眼前东西的习惯。而CEO要对整个公司负责，CEO的目标是让大家过得都好，而CTO是我做的东西是最好的，两者视角不一样，发生冲突也是常见的，但很多时候CTO还是要遵从CEO的愿望的。

某企业级垂直门户网站CTO评论：CTO其实有时候是要像CEO一样去思考，应为像CEO一样去思考是一个很好的境界，否则就会容易从技术层面出现一些分歧，一个CTO出现的技术分歧会影响下面很多技术总监和技术人员的想法，他们在整个业务配合中就会出现很多的不和谐关系，但是CEO考虑的层面会更大一些，会从公司整个战略方面去考虑，所以要求所有的不光是CTO，包括CMO、CIO更多的情况下思想上应该是像CEO一样去思考。

• CTO要有选择性的参与企业例会
  
  

某企业级垂直门户网站CTO评论：我理解的例会指的是CTO职责范围内的例会。可能有很多种，比如说一个CTO可能会管技术、产品开发、运维，再到前端后端之类，我觉得例会，第一，总体公司的管理层例会必须要参加；第二，一些主要的例会，主要产品立项的例会肯定要参加。剩下的会议就要有选择的参加了。比如牵涉到业务部门的某些具体例会就没有必要参加，还有开发部门自己的例会，可以有选择性的参与。同样道理，例会肯定要选择性参加，上层的和平级之间的例会CTO肯定要尽量参加，因为需要了解公司的整体运营情况，而下级的例会我觉得可能要有选择性的参加，如果是功能性或者是非协调性的会议就可以先放一下。

• CTO不必非要是技术出身
  
  

某安全创业企业CTO评论：我觉得投票的这些人的背景可能都是技术出身，他们有一个良好的愿望就是，以后可以成为一个大公司的CTO，但是事实经常是做了多年技术细节的人很难最后成为大公司的CEO。那么，如果不懂技术是不是会让下边人心中不服，这实际是技术人员的一个陋习，很惯性的去以技术评定CTO这个人。实际从公司角度来说，公司更认可的是你能不能给公司带来业务上的支持，这是公司盈利潜在的发动机，你的技术好与坏和你带整个团队在技术上走得越来越远，越来越快，越来越精，这不是一回事。所以我觉得说懂点技术是好的，就是到了CTO这个层面，如果你是技术出身是好的，毕竟你的项目都是要带技术人员来完成，但真的没有必要对技术是如何如何的精通。

编辑总结

当我们看完调查结果，听完众多CTO、以及技术人员对此次事件的评论后，再来看近期某医疗互联网公司前CTO所引发的这次事件。我们会发现，无论是企业的CEO，还是CTO本人，亦或是技术人员，其实都不太会把会不会写代码作为对一个合格CTO的主要考核标准。换句话说，没有一个CEO会对CTO是不是亲自写代码那么“感冒”。所以说，关于CTO要不要亲自写代码的这个问题从某种意义上说应该算是一个假命题。那么，为什么还能引起这么大的反响呢？原因是，很大程度上公众在看待事物的时候，通常最先看到一个事件中最尖锐的焦点，而更深层次的问题往往就会被忽略掉。

另外，我们在调查中，也发现有些企业要求CTO要亲自参与代码的编写工作。从问题1和问题2所对应的投票比例可以大致看出，大、中型企业一般对CTO是否需要亲自编写代码都不太关心，而只有一些小型企业或创业企业的初期往往会更看重CTO的这一基本技能。但也无可厚非，出现这种结果，主要是企业在不同发展阶段对CTO有不同定位造成的，而这次事件的导火索可能就出现在了企业定位与CTO自身定位发生了分歧，最终导致了此次事件的发生。

所以，根据这份调查，我们的结论是，CTO的职责与核心价值应该是随着企业在不同发展阶段的改变而变化的。作为CTO，你懂运维，你会编写系统，甚至你是某项技术的创造者，这些很重要，但关键是能力和当前业务需求的匹配性。如果匹配不好，CTO往往就很难伴随一家企业的全过程发展。综上所述，管理层目标和团队需求，以及CTO自身对职业生涯的定位，这三个因素共同决定了一个CTO的工作重心应该放在哪里，写代码可能是一个问题，但不是一个关键问题。