[转]CTO是否要写代码？

by leelight · Published October 5, 2018 · Updated December 15, 2018

首先我给大家看看 CTO 应该干什么，或者说一个技术人员，互联网公司都会遇到所有这些事。这个坐标轴最左面是操作一级的，比如说写代码、测试网络、测试、搭防火墙、写脚本等等，到这边是管理上的事，再往那边是领导上的事情。这个方向是公司的规模，公司的规模越小需要操心的具体事越多，公司的事越大，你需要的领导力越多。除具体的事以外，还有流程、监控、规范、技术氛围、交往、技术体系、预算、公司的技术形象、公司技术方向、技术战略，事很多。

我用红颜色和绿颜色做了区分，红的从左到右，架构、人才、组织、战略、业务、技术形象、技术方向、预算体系、行业、氛围、规范、流程，这些事应该谁管？是写代码的人管，还是 CTO 管？在这种情况下，CTO 还要不要写代码，CTO 如果写了代码谁来管上面这些事？我粗浅地给大家归归类，CTO 应该干什么，CTO 该聚焦什么。

CTO 核心是围绕着技术，围绕着技术干什么事呢？如果一个公司 CTO 只聚焦在技术上，连个兵都招不进来，因为你公司文化不好，公司的一个技术组织怎么样去规范，靠 CTO，还是靠人力？有的 CTO 就说那是人力的事，但是人力怎么用 CTO 的角度和视野把人组织好？人力更多是从人力资源的专业角度，帮助你在整体策略下做一个组织设计。CTO 一定要围绕着技术，管好自己的人，管好自己的组织，把自己的过程优化，然后管好公司文化。不管怎么样，CTO 都是文化少不了的最重要的担当者。

CTO 要不要做 DBA 管一管数据库，要不要搞一搞网络呢？国内的研发、技术人员，往往以研发为核心，或者研发为最主要的，只看到研发，很多 CTO 来源都是研发人员，除了研发以外，还有测试、网络、安全、配置、系统、数据都是技术人员，每个行当都需要自己的发展空间，如果不把他们按初级、高级、架构师组织起来，测试员可能干到高级阶段以后自动就走了，因为在你这儿没法发展。同样网络，你的安全人员，如果没有架构的支撑，或者是职位的设计，干到一半走了，所以一定要把你的各个兵种都配齐了，各个兵种相适应的不同的台阶也都打开，这样大家不断地在自己的职业发展方向上去优化，你的人会越聚越多，也越来越好。

除此之外这四个才其实挺有意思的，你作为 CTO 你怎么管人，你管不管人？考核技术总监，或者高级总监，就看一件事，管人的事，上半年裁了多少人，这很关键。我们的人要区别考评，特别注意裁掉企业文化也不好，技术能力也差的人。有一种人要特别裁掉的，就是技术水平特别高，企业文化很差。只要是跟大家讨论问题，就把自己的位置调很高，之后什么事情都讨论不了，这种我们叫高技术的混蛋。除了裁掉人，我们要保留精英人才，这是企业的财富，既有企业文化的培养，又有很好的技术能力。还有就是技术能力很好，但是企业文化稍微差点，比如说刚进到公司里的，这种人我们要培养他从第二象限移到第一象限，这就是我们要及时考评区别对待。

讲考核我们技术人员的时候，不能像考核产业工人，产业工人是什么？产业工人是靠时间，比如说你来八个小时，我每小时给你多少钱，然后你来给我工作，考核技术人员考核的是什么？他的人肉时间还是他的智力时间，我们考核的是智力时间，就是说你坐在我这边是不是凝神静气想了 15 分钟给我写了一段代码，而是说你在这儿八个小时上了 N 次卫生间然后回家了，这个差别很大。要解决这个问题最重要的是用 OKR 来考核。还有特别注意及时鼓励。游戏就是及时鼓励，你玩游戏 5 分钟就能得到鼓励，就能得到很好的精神安慰，我们的研发人员也需要这个，最简单是每个月以 CTO 的名义发一期 CTO 简报，把你公司技术做的好的都讲一遍，下面的兄弟一看我老大很重视我，下个月玩命干活。

我们把人都找齐了，要注意怎么组织起来。如果大家去传统的银行会看到，这种高塔式的结构，一级一级往上传，而互联网公司多数是扁平的。在小的公司，老板如果指挥大家，都清楚做什么，目标一致，就容易出现好的创新主意出来，所以保持扁平化的管理，对 CTO 很重要。

现在很多公司是军队管理体系，骑兵和骑兵在一起，步兵和步兵在一起，炮兵和炮兵在一起，他们在一起有一个职能线，应该把这个架构转 90 度，会变成什么呢？不同兵种的人，研发、测试、运维、网络他们在一个小组里，头上有一个指挥的，头上顶着都是业务指标，他们跑到一起，就是为了共同的业务目标把事情做出来。这边是我们要把一个项目做出来，项目做出来赚没赚钱跟我没关系，所以哪一个会出现好的结果呢？一定是右面这个，所以我们 CTO 要适合这种互联网的快速发展和复杂的情况，应该做成比较靠右面的情况。

CTO 要注意组织。现在穿蓝衣服的都是高尚的，穿白衣服的都是卑鄙的，你们马上互相打起来了，其实这就是组织，只要有组织边界就有矛盾，它对恶性冲突是有刺激作用的，结果就是大家在一起天天打架。而经验多样性就是有 70 后、80 后、90 后，有做测试、做研发、做运维的，不同经验的人在一起完成一个项目，好的目的有相互协同作用。认知冲突是指看待问题的角度不一样，一个项目运维看待和研发是两个角度，要把最优的方案提出来。想创新就需要给大家授权，充分信任。还有认知要多样性，这样才能最大程度促进组织内部，互联网内部的创新传播。

还有采取小团队制度，不超过 8 到 10 个人，因为手就十个手指，多一个就需要这个人有特别的训练，每增加一个是一个指数级的增加，所以尽量减少你团队的人，让大家在一个可控的通讯空间里，减少互相沟通的机会。

关于文化，我个人认为 CTO 绝对要管文化，而且要有技术的亚文化在公司存在，这样才能招到和保留好的人。刚开始我到易宝的时候，大家都闷头干活，也不多交流，我们就找新技术来刺激大家，每周都会引进新的东西让大家尝试，久了大家说跟这个老大混能学到不少新东西，从外面引到最新的技术，团队的凝聚力和成长的动力都会增强。还有就是鼓励创新，在易宝支付做创新 24 小时，其实就是把人关起来，在里面让大家创新。做得好我可以投资，成立公司，然后你去做老板。做的不好的，大家完善，你可以再接着想，以后再创新，最大程度鼓励大家往新的业务思想基础方向去琢磨。还有就是避免有一些假装创业的人出现，突然脑子灵光一动想我很牛，我要创业，结果主意提出来了，公司说行你搞的好，钱也给你配上，结果大家一论证这个主意不行，回来老老实实干活了，这也是另外一个帮助。

文化方面要树立正确的技术负债观。当你空降到某一个公司做 CTO，感觉遍地都是坑，这些坑让大家认识到都是技术负债。先把技术负债的概念搞清楚，如果我们花一个研发资源，两个人一个月做了一样东西，有些功能因为时间或者别的原因无法实现，这部分就是我们所谓的坑，也就是负债。这个负债就跟公司的财务报表一样，你要记到你的报表里去，说将来有那么一天呢，我有了人手，我可以把它再还上，我们借信用卡都可以负债，技术更可以负债。有一个好的技术负债观之后，既能记住前面几任欠了多少债，也能搞清楚以后欠多少债。

除了人员、组织和文化以外，最重要的是过程，这个图讲了三层意思。第一层意思是讲任何系统它都有自己可以出错断裂的点，这些点的存在是不可避免的，系统都是高耦合的，里面一定存在各种断点。这种断点在正常情况下相安无事，系统走起来很正常，一旦有风吹草动，比如说一个特别不正常的输入，不正常的网络延时，就会造成这些断点被触发。一旦触发会怎样？第一种可能是先报问题，另一种是连问题都不报，直接系统失败。所以我们希望的是看到那个报的问题，过程要聚焦在红点上，不要聚焦在触发这些问题的人上，这样你的系统会越来越健康。

中国 ITIL 体系用的不多，这是行业里最佳实践的总结。规范化总是意味着麻烦、不简单，做事太多流程要过。但你要想保证系统长治久安，特别是关键的系统，需要一套系统可用性管理，事故管理、问题管理。所以 CTO 根据自己公司的技术现实选择合理的管理体系也很关键。管哪些点，怎么管，把这个体系引进来，这是最佳实践，但很少有人认真的使用。

过程需要不断成熟，不断完善，让过程定量化，有一句话叫管理就是度量。不断地度量你的过程，有问题及时修正，最佳结果是流程用到最后没了，系统自动化了，或者是你的人素质足够高。

除了要注意管理体系外，最好用自动化，机器不犯错，还无怨无悔地干活，用智能的运维替代我们通常的人肉运维，是解决我们好多技术问题的一个关键点。

结论就是作为 CTO，我们要关注人员、关注组织、关注文化、关注过程，通过我们的技术来服务我们的业务，所以最高的目标是业务，技术只是服务业务的一个手段。

 

陈斌，现任易宝首席技术官（CTO），一直专注于互联网技术领域的探索和创新，拥有丰富的海外经历、多年的架构经验，深谙移动互联网对传统行业的影响。

 

[source]CTO是否要写代码？

Related posts:

1. [转]架构师不写代码，能行吗？
2. [Repost]How my role as CTO has changed as we’ve grown to 100 engineers
3. [转]如何转变职责从码农到管理数百人的CTO

Share

Tags: Project Management

You may also like...

• 0

  [Repost]How my role as CTO has changed as we’ve grown to 100 engineers

  December 4, 2018

   by leelight · Published December 4, 2018 · Last modified December 15, 2018

• 0

  [转]称职的技术leader相当于100名工程师

  September 26, 2018

   by leelight · Published September 26, 2018 · Last modified October 29, 2019

• 0

  [转]如何转变职责从码农到管理数百人的CTO

  December 4, 2018

   by leelight · Published December 4, 2018 · Last modified December 15, 2018