在不同的行业中，以及不同公司在不同阶段，对 CTO 的要求是非常不一样的。同时任何一个时期，对 CTO 的能力要求其实都是综合的。

我所在的公司是一家创业公司，我是公司的联合创始人和 CTO。我想结合我在公司不同阶段的经历，谈谈我对 CTO 这个岗位的认识。

公司初创期

大多数互联网创业公司，一开始都是从几个人开始干起，我们也不例外。这个阶段最重要的是如何快速开发，快速试错，通过试错不断验证自己的 idea 是否靠谱。而对于技术架构是否可扩展、研发流程是否规范、绩效考核等则不会过多考虑。

记得我们在开始第一个产品的时候，直接写 JSP 页面，不需要前后端分离（因为我们也没有专职的前端），数据库则用了 Schema free 的文档数据库 MongoDB，无它，就是追求最快迭代开发速度。

这个阶段的公司，应该建立怎样的认知呢？首先是创业越早期风险越高，其次是低成本试错。那么作为 CTO 或者技术负责人，你的决策也需要匹配公司当前的状态。

比如招人方面，从匹配性上看，如果候选人没有创业心态，过于追求安稳，就可以 pass 掉；从技术画像上看，一个全栈工程师会比一个技术专家更能帮助到团队。

比如技术选型方面，不要犯杀鸡用牛刀的错误。尽量选择轻量级的框架，考虑最大化团队的开发效率为核心。在产品还未被被验证之前，过于超前的为大规模用户使用、超高并发和海量数据访问投入设计，很可能最终只能轮为摆设。因为产品的死亡率极高，方向也随时可能发生变化。

网上流传着腾讯的 QQ 服务端架构从建立初期一直沿用到现在的说法，腾讯的 CTO 张志东在一次内部培训中被问及此事时，很坦诚地说，其实 QQ 的架构一直在不停的改造和优化，到目前为止已经做了 4~5 次的调整。当初创业时候的规划是：第一年同时在线人数到达 1K，第二年 2K，第三年 4K，第四年 8K，第五年就可以上万了，而实际上第五年的时候腾讯已经做到了 500 万的同时在线数，目前 QQ 支持的最大的同时在线人数已经超过上亿。张志东说，如果 1998 年创业初期，就让他做到支持 500 万的同时在线人数，可能就不敢创业了。

高速发展期

一旦你的产品通过了用户和市场验证，公司可能会进入了新的发展阶段，这时候你才有机会接受进一步的考验。随时用户和业务的增长，产品需求可能越来越多，公司对产品的迭代要求更高，老的技术架构已经不能适应新的业务迭代，同时管理层也越来越关注产品的稳定性对客户的影响，你的团队人员在不断的膨胀，而你还没有准备好绩效管理，也还不知道如何去淘汰不合适的员工……

开始接近自己的创业梦，发现梦想并不是想象中那么美。在公司的高速发展期，问题产生的速度远比你想象中快。这个阶段的 CTO 应该建立怎样的认知呢？

我总结有三点方面的思考非常关键：

第一，抓大放小，区分主次。分析清楚当前主要矛盾和次要矛盾，重点解决主要矛盾。把当前的问题、内外部需求、公司的规划进行梳理对比，找出核心问题，重点投入。

在我们公司发展历程中，曾经遇到一些问题。首先是团队效率，在人员膨胀的情况下，如何保证做到小团队作战的人效。亚马逊的 CEO 杰夫·贝索斯有个“两个披萨原则”，如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了，沟通协作的效率很容易下降。把团队按业务或职能切分，可能是更好的方案。如果你的团队人员扩充上去了，生产力并没有跟上，那么是时候考虑团队规模是否太大的问题。

如何平衡各种需求？在我们公司的发展历程中，早期产品稳定性是我们的核心问题，当时我们内部同事也会反馈说竞品有这个功能那个功能，而且网站上页面看起来比我们舒服多了，这些需求我们能不能做？记住，资源永远是有限的，次要的功能不做不会影响用户的核心流程，页面长得不好看也不影响用户的使用。但如果产品不稳定，那客户是要跳起来的，所以我们早期研发的重心之一是做稳定性优化。

第二，追根溯源，从源头解决问题。特斯拉的 CEO 埃隆·马斯克倍受推崇的“第一性原理”思维，就是强调在基本事实的基础上探究问题的本源，不被过去的经验知识所干扰。在高速增长期，我们也会遇到各种各样的问题，从根源上解决问题才不至于反复的疲于应付。

比如面对产品的故障，是每次修复完就忙于下一个需求，还是重视复盘总结问题根源？这一点《SRE Google 运维解密》这本书提到的“事后总结制度”做得非常到位，除了追溯问题本质原因外，还建立了良好的总结文化，会收集事后总结内部分享，开放评论，对于良好的事后总结和事故处理还会做公开的奖励，甚至可以得到高层的点赞。

再比如技术债，技术债累积越多，后期的研发效率、问题隐患越多、维护成本越高，适时的解决技术债问题，是从长远考虑非常有价值的投入。

第三，充分放权，有效监督。早期小团队作战，也许还能靠几个尖兵一招鲜，快速占领先机；中后期拉开战场了，必须要依赖团队作战，依靠制度管理。

首先，早期成长起来的 CTO，长期战斗在一线，冲锋陷阵以身作则的品质自然是不用说的。但是作为最高指挥官，最难得的是需要自知和自省，知道自己的短板和优势是什么，知道如何补自己的短板，不管是找到比自己更强的人，还是依赖团队的力量，这要求 CTO 具备有大局观和开阔的心胸。我们看到很多公司设立技术委员会、架构组等技术决策层，也有些公司设立联席 CTO，其实是非常好的尝试，既下放了一些技术决策权，又补充了 CTO 可能的技术短板，同时也可以根据需要，对 CTO 的技术决策权做一定的约束，形成互相监督。

其次，团队作战，也讲究排兵布阵。按业务切分，还是按职能切分？还是更复杂的混合架构？孙子兵法曰：“知己知彼，百战不殆”。需要结合团队成熟度、业务特点和竞争格局考虑，要求 CTO 除了了解自身团队特点，还要熟悉行业竞争格局，以制定出最强有力的打法。阿里巴巴搞出了“大中台、小前台”组织架构，即作为前台的一线业务会更敏捷、更快速的适应瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。

最后，有不同的团队，就需要更多的将军。在这个阶段，要有意去选拔和培养合适的 leader，建立人才梯队。但人才培养、团队建设都是一个长期的过程，并非一蹴而就。高速增长的阶段，也要适时去补充能独当一面、身经百战的大将，在专业能力、技术视野、管理经验等方面补充团队的不足。不至于出现“蜀中无大将，廖化作先锋”的悲哀。同时对于新上任的将领，作为将军需要知道每个人的局限在哪里，每个人都不是完美的，要知道如何去补位和防范，以制定有效的监督。

稳定发展期

经历了早期的试错和高速的发展，公司可能会进入一个相对稳定的发展阶段。为了公司长远发展，公司需要不断的进行新业务探索、不断进行技术的创新，CTO 对新技术的判断力和商业敏感度会越来越重要，CTO 的视野关系着公司的未来。就像前微软 CTO Nathan Myhrvold 所说：“My job at Microsoft is to worry about technology in the future. If you want to have a great future you have to start thinking about it in the present, because when the future’s here you won’t have the time.（我在微软的主要工作是关心未来的技术。如果你想拥有一个美好的未来，你现在必须开始思考它，因为当未来来临时，你就没有时间了。”）

我们也看到了很多优秀的公司，在技术上所做出的超前布局。全球公认的最优秀的 CTO 之一，亚马逊的 Vogels 在一次采访里介绍了 亚马逊在机器学习领域的技术布局。他介绍说，在过去的 20 年间，已经有多达数千位软件工程师在亚马逊参与了机器学习项目。他认为亚马逊是一家在业务领域使用人工智能和机器学习技术的前沿公司，也正是因为不断地创新，才会让业务发展不断突破瓶颈。

写在最后

就像电影《后会无期》中所说的：“听过很多道理，却依然过不好这一生”，每个 CTO 的经历和挑战大不相同，只希望以上分享的经历能抛砖引玉，对大家能有一点帮助。

在创业路上共勉！

作者简介

林佳齐，云片网络 CTO，TGO 鲲鹏会杭州分会会籍委员 & 服务委员。2010 年加入淘宝，参与淘宝搜索技术的改造与优化、淘宝去 IOE 等项目。2012 年创业，负责技术团队搭建和管理、核心产品研发和运维保障。从为淘宝商家提供 CRM 服务的维客软件，到为企业提供短信、语音、流量等服务的云片云通讯平台，对高可用、高并发系统架构设计有丰富的实践经验，对于云通讯技术和稳定性实践有深厚积累和独到见解。