如何成为一名合格的CTO?（转）

本文来源于微信公众号“线性资本”（ID：LinearVenture）

成为一名合格 CTO

我们投过很多技术型的公司，对于什么是合格的 CTO 有过自己的一些思考。最近关于什么是一名合格的 CTO 有些争论，我们以Q&A 的方式分享一些我们的看法。这些看法一方面有时候会影响到我们投不投一家公司，一方面也是从被投公司的历程中总结出来的。

CTO 的定义是什么？

根据其定义，Chief Technology Officer，就是技术方面的最高负责人。和Technology方面相关的问题的争论在 CTO这层就停住了，CTO的回答将是最终回答。No appeal, no further escalation. CTO如果自己无法独立回答该问题，他或者她应该想尽各种办法寻找各种帮助最终做出决断。但回答该技术问题将是他的最终责任。就好像司法上面的最高法院 - 判决将是最终的。即使是错误的，也是最终的。所以一个 CTO 的水平将会最终决定一家公司的技术水平。

但这不代表所有的技术问题都应该是 CTO 来回答。用司法系统再次做个类比，各级法院在其职责和能力范围内尽可能的进行司法实践。同样的，尽可能的将技术问题控制在负责相关实践的技术人员那边，直到争论产生或者技术小组无法独立回答。

上面谈的技术是事方面的责任，硬币的另外一面是人方面的事务。CTO 里面除了Technology之外，另外一个不能忽视的关键词就是 Officer。Officer 是一个 leadership role。一个领导位置。好的领导是一位管理者但多于管理者的角色。他需要打造团队不然没有队伍可以领导，光棍司令要么过劳死，要么拖公司发展后腿；他需要发展(grow)，激励(inspire)，刺激(motivate)，挑战(challenge)队伍，不然队伍无法发展超越自我；他是一个榜样，他需要说一套就做这套，因为技术团队里面的人会以他的言行作为自己行为的一个对标。最好的 leadership 是 lead by exmaple. 他需要去挖掘和培养团队里面的其他有领导潜质的人不然团队没法 scale。我记得从工程师转做 manager 的时候我们 VP 专门找我聊了下，其他都忘了，我记得这一句

『I don‘t care about your personal success. I care about your team‘s sucess. As a leader, your job is to make them successful.』

（我不在乎你的个人成功，我在乎的是你的团队成功。作为领导，你的职责是使他们成功。）

一个 CTO需要在必要的时刻站出来保护自己的团队，因为公司的政治在发展过程中会不可避免的出现；与其像某BAT公司那样内部宣布不允许政治，但其实比谁的政治斗争都多，不如坦然的对待，把一些利益纷争放在台面上来讨论。

所以纯粹的只讨论管技术不管人的 CTO 是不合格的。有些公司的选择是到一定情况下，将 CTO 和 VP of Engineering 的角色分开，前者只管技术，后者更多管人和文化，也是一种选择。这个时候的 CTO 里面的 T是重点，而非 O。

 CTO 最核心的职责是什么？

保证核心产品能够保质按期发布。

不管是前面提到的技术，还是技术人员的管理，『最终』不是为了建立一个『伟大』的技术架构。最终目标是为了能够发布产品，解决问题，满足客户，占领市场 - 这是一家商业公司的核心所在。CTO 的职责是为核心服务。

重点虽在今天，但也要为未来产品快速迭代和持续发布做好准备。

CTO 到底需不需要coding？

不需要。

但是，早期除外。

早期的时候啥都缺，很多事情都需要 CTO（有时候包括 CEO）亲力亲为。这个时候是不需要讲太多规矩的。没有队员就自己上，没人会，组织人学了上，包括自己。但CTO作为 IC (individual contributor) 应该是暂时的行为。尽可能通过寻找到更加专业的人来做具体业务的编程。不管是前端，后台，数据，全栈等等，刀应该是越磨越锋利。CTO 是操刀的人，不应该是刀本身。

CTO需不需要懂编程？

CTO 必须懂编程，很懂编程。

他应该是个很好的工程师。如果他需要，不应该超过3个月可以重操旧业成为很好的程序员。只有这样他才能和其他工程师有好的沟通，在必要的时刻介入到技术框架讨论中不会鸡同鸭讲，被自己的手下鄙视。

CTO 要不要参与做核心技术的选型？

只有在自己擅长的领域内或者团队没法自己做出有效决策的情况下才介入。

这里涉及一个做核心技术决策时候的原则"let the expert decide"。 如果你就是那个最好的 expert，你来。这个时候你不是以 CTO 的角色，而是以一个领域专家的角色参与讨论。另外一个原则就是尽可能让负责实践的团队来决策。一个施工团队是受一个技术选型决定的影响最大的一方，他们最有动力花时间来深入研究，去做一个将来不会让他们难堪的决定。如果有必要，CTO 可以利用自己在行业里的关系链邀请最合适的外面专家给团队分享案例提供建议，但不要将决定权交给外面的专家。

而当团队陷入一种争论而无法独立做出决断的时候，假如你相信你的队员们，这个时候你可以参与做个仲裁；因为如果胶着的双方都优秀的话，被争论的技术选项不应该存在一种会比另外一些选项明显好很多的情况。Just pick one and move on. 作为 CTO，你要明白争论在什么时候是足够了，什么时候该做个决断了。

CTO 要不要参与代码审查(Code Review)？

首先，不积极推动 Code Review 的 CTO 不是合格 CTO。明显没有全局化视野和对长期效率的深入思考。

有了 Code Review 的机制后，我建议CTO应该经常看看核心部分的代码，以保持对于自己团队代码的熟悉程度。

读代码就像读书一样，时间久了不读书，会失去对文字的感觉。但不一定要全读。核心系统的核心代码，和公司碰上的大 bug 时候，都应该经常看看。前者对于自己公司的最核心的技术实现有个第一手的了解，知道强在哪里；后者可以了解自己的团队通常是磕磕碰碰在什么地方，知道弱在哪里。

CTO是否应该参加核心系统的架构讨论？

应该。

如果一个 CTO 来自己最核心的系统的大体实践都不了解的话，没法在必要的时候介入做最终的技术仲裁；也没法知道需要招什么样的技术人员来发展团队。前者是做事，后者是做人。而事和人都是应该为了系统服务的。系统，当然是为了产品服务。

CTO是否应该参加核心产品的讨论？

应该。

产品需要实现，只有清楚核心产品是什么，才知道需要什么样的核心系统，然后才是什么样的技术和人才。所以CTO参与核心产品的讨论非常重要。

CTO该不该主导工程师文化和制度建设

CTO 的主要职责之一。

CTO 是一个 leadership role。团队小的时候，管理相对容易，大家主要就事论事即可。团队大了，不管你愿不愿意，会逐渐分层，你需要逐渐的去发展中层干部，也要逐渐思考文化建设。所谓文化建设，就是一个形成共识的过程。这种共识是关于什么样做事做人的风格是被鼓励。文化无关对错，文化是一种选择。

很多创始团队的早期CTO 如果没法随着公司的成长而成长起来，还是天天陷入到某块具体代码的局部战争中去，动辄就介入具体的执行，一不放心就自己啥都管管，不懂得delegate，要不就是放手就完全不管，不懂得validate。师长做了排长的工作。

如果一家公司的 CTO 只想管事，不想管人。要么加一个 VP of Engineering分管人，要么把 CTO 的位置让出来给到更合适的人选。

CTO应不应该经常走出去和外界交流？

虽然并非必须，但这是区别于一个合格 CTO 到卓越 CTO 的重要的点。

走出去，一方面可以将自己公司在技术这块的事和人方面的问题暴露出去。达到高水平的前提是你和高水平之间是联通的，这样两个水面才有机会平起来。除非你很自负的认为自己就是比剩下的世界要牛很多。另外一方面，可以将自己公司取得的一些成就展现出去，自己公司的文化特点展现出去，能够更好的吸引牛人进来。前面提到CTO 一个重要的角色就是要打造团队。团队的前提是牛人；吸引牛人的前提是别人要知道你。CTO 不走出去和业内多交流，指望猎头找来牛人多半是不靠谱的。

但要区别有效交流和饭饭之交。前者是需要扎实的去分享，去给社区做贡献，花钱花精力把牛人请进来做分享，大家做深度的无保留的探讨。后者主要是饭局交流，泛泛之交，并没有讨论到具体带人处事的实例的交流。后者虽有些价值，我们作为投资人干干可以，对于CTO 意义不大。

在这一点上，可以借鉴下这篇文章(注：http://www.svpg.com/what-makes-a-great-cto/）关于 CTO 的Evangelism（布道）上的角色

The CTO will serve as the company spokesperson for the product development/technology organization, demonstrating leadership in the community, with developers, partners and customers. This is often measured by establishing a university relations/recruitment program, and sponsoring or participating in at least two events per year in the developer community.

CTO 应该和什么人做经常性的1 on 1？

常规性的1 on 1 应该包括CEO + VP of Product + direct reports + 核心产品的技术负责人 + 架构师。另外对于即将从工程师转到管理岗位，Manager升到 Director 等的人员，应该在考察期间交流一到两次。

以上只是我们的一家之言。成功的 CTO 也许和成功的 CEO 一样，可以出身迥异，风格不同，但最终到底，一定是围绕 Technology 将 Chief Officer 的角色扮演好。