CTO 到底该不该写代码？——宅米 CTO 李智慧访谈

前段时间大家热议，CTO 需要些什么样的素质？到底该不该写代码？在即将于 10 月 20~22 日举行的 QCon 上海 2016 上，我们邀请到了宅米 CTO 李智慧。今天，我们请李智慧老师谈一谈他对 CTO 这个角色的理解。

李智慧，宅米 CTO，前 NEC 项目主管，阿里巴巴技术专家，IBM 咨询经理，Intel 大数据工程师；开发过 ERP，写过防火墙，做过网站架构，搞过数据库，带过团队，创过业，申请过几个分布式系统专利，为 Apache Spark 贡献过一点代码；写过一本《大型网站技术架构：核心原理与案例分析》，被若干高校选为计算机类专业教材。

QCon：很多人都知道，您所学专业并非计算机，当初是怎样入门的？又是如何一步步成为一名 CTO 的？

李智慧：我大学时候学的专业是工业自动化，在实践中应用的是那种成套的昂贵的大型工业自动化系统，而我们上的专业课，每一门课都是这个系统的一个小的局部，我没有办法在头脑中形成一个全局的系统的印象，这让感到我特别痛苦，我不知道这些分散的孤立的知识点是如何整合起来的。

所以，当第一次接触计算机编程、第一次上机编程、第一次发现只需要输入几行代码就能构建出一个独立的整体，就可以完整运行的时候，我欣喜若狂，遇到梦中情人般地激动。每一次小小的改动就能使程序的运行结果会完全不同。这种及时反馈带来的刺激像打游戏一样，于是我迅速对编程进入一种痴迷状态。每天学校机房还没开门，我就坐在门口拿着一个本子在上面手写代码，等开门了就上机实践。

前面提到，我对事物的整体的全局的系统的认识有一种执念，所以后来在工作中参与大型软件系统开发的时候，特别关注系统整体架构。为了让软件架构更合理更完善，我开始参与开发一些框架和工具类的软件，又逐渐地负责一些规模较大的系统架构，有时候也被人称作架构师。架构师是一个需要兼顾技术与管理的工作，要想让自己的架构设计落地实施，需要各种计划、组织、领导、控制的技巧和能力。至于后来去做 CTO，只是职业选择罢了，和架构师相比，更偏重管理一点，对能力要求差别并不大。

QCon：最近网上都在热议 CTO 到底该不该写代码，您怎么看？CTO 在一个公司的定位到底应该是什么？

李智慧：我的看法，CTO 应该写代码，也不应该写代码。应该写代码是说，CTO 需要通过写代码对技术保持敏感，而不是一个“嘴炮 CTO ”，“ PPT CTO ”；不应该写代码是说，CTO 工作的重心不是代码，通过写代码为公司创造价值是相对低效的，当 CTO 写的代码出了问题的时候找不到 CTO 怎么办。

所以我的观点是，CTO 最好参与一些开源软件的开发，保持对技术的敏感，最好不要写公司的业务代码，避免出了 BUG 却找不到 CTO 修复。

关于 CTO 在公司的定位，我认为以下有两个方面。一个是技术团队内部的，包括整体技术方向的决策和把握、流程规范的制定和推行、工程师文化的建立与发展、团队成员的进步与成长、组织结构的划分与整合、团队成员的管理与考核、技术大牛的招聘与引进；另一个是团队外部的，包括主导技术部与其他部门的沟通与协调、参与公司战略决策并评估技术代价与风险、为技术部门争取必要的资源和利益。

QCon：您曾提到“创业团队不需要 CTO ”，那么在您看来，创业公司是否可以分成几个阶段，又是在哪个阶段开始需要 CTO？

李智慧：在过去的一年中，作为一个收费咨询项目，我大约和三十多位互联网创业公司的创始人聊过这个话题，大部分公司处于 A 轮融资之前。这个阶段的公司处于产品验证阶段，就是说，产品是否真的有用户价值、是否被用户接受、是否真的有商业价值、是否有可靠的盈利模型，需要在这个阶段进行实战验证。这个阶段的技术挑战主要是快速进行产品迭代，不需要复杂的技术架构，也不太有高难度的技术挑战，只需要一个精悍的技术小组，一个小组 leader 即可。

产品经过验证，用户价值和商业价值得到确认，公司经过 A 轮或 B 轮融资，企业进入规模化发展阶段，用户量和数据量急剧增长，系统越来越复杂，技术挑战越来越大，这个时候就需要一个 CTO 了。CTO 可以是外部引进的，也可以是前面的技术 leader 提拔的，判断标准就是，这个人是否能够和公司一起成长，实现公司最终的战略目标，达成组织最终的愿景和目标。现实一点说就是，能否帮公司成为独角兽或者上市，能否支撑得起这样一个局面，能力、格局各方面够不够。

QCon：现在正处于“创业热”时期。作为合伙人，如何选择创业伙伴？作为从业者，又如何判断一家创业公司是否值得加入？能分享一下您的经验吗？

李智慧：选合伙人就和找对象一样，是非常主观的一件事。我个人希望选择那些聪明并且真诚的人做创业伙伴：聪明能够让我们洞悉事物的规律，找到达成目标的最佳路径；真诚能够让我们坦诚相对，彼此信任。创业是一趟“地狱之旅”，各种磨难，九死一生，如果终究要死，和这样的伙伴在一起大约能死得体面一点。

看一家创业公司主要是看它的创始人，对于创始人而言，我觉得最重要的是要具有一种领袖的魅力，拥有坚定的信仰和永不言弃的精神。

QCon：毕竟大小型公司的组织架构不同，从大公司获得的管理经验，哪些适合用在创业公司？

李智慧：和计算机科学一样，管理也是一门科学，管理方法、组织行为具有普适性，受公司大小影响不大。但是同时，小公司又和大公司不同，小公司人员素质层次不齐，团队又没有经过磨合，所以一方面表现出热情高涨、斗志昂扬，一方面又表现出各种混乱、执行不力。

个人经验，如果能理解自己过往经验背后的逻辑，就能灵活应用于新的环境，如果只是生搬硬套过往的方法，十有八九要碰钉子。不论在大公司还是小公司遇到管理问题，都应该真诚地面对问题、分析问题、思考解决办法，而不是气急败坏、寻找替罪羊、开除某个人、为自己失败的管理开脱。

QCon：很多技术人都被贴着“不谙世事”“不善言辞”的标签，在这样的特质下，从技术人员转到管理人员会面临哪些挑战，该如何应对呢？

李智慧：工程师在组织中的定位是“解决问题的那个人”，工程师的价值在于解决问题。人情练达、世事洞明、口若悬河这些特质有助于更好地解决问题，但是并不是解决问题的必要条件，解决问题的必要条件是“精湛的专业技能”和“对问题本质的把握”。最终你还是要解决问题，而不是通过语言和交际能力让别人以为你解决了问题。

个人经验，那些在工作中“不谙世事”“不善言辞”但是专业能力和问题洞察能力强的工程师，大家可以很快地适应他的“直截了当”和“率真”，反而更招人喜欢。

QCon：听说您的《大型网站技术架构：核心原理与案例分析》已经卖了几万册了，您觉得“个人影响力”对技术团队管理者来说重要吗？该如何提高？

李智慧：个人影响力可以分为两个部分，“外部影响力”和“内部影响力”。外部影响力主要通过出版图书、技术演讲、撰写博客，以及在各种社交媒体上曝光获得。就我观察，外部影响力对技术团队管理的作用相当微弱。作为一个“名人”，一开始会受到更多关注，但也仅此而已。真正对技术管理起作用的是内部影响力。如果公司的核心技术框架是你开发的，关键工具是你写的；如果工程师们遇到问题，第一时间想要请教的人是你；如果技术决策争执不下的时候，总是邀请你出来仲裁。那么，你在技术团队的作用就举足轻重了。

在我看来，技术管理其实就是“影响力管理”，通过自己的个人（内部）影响力，对公司（项目、产品）的技术决策、技术方向、流程规范产生影响，进而达到管理的目的。通过“影响力”（内部影响力）进行管理，而不是通过“权威”（外部影响力）和“权力”（头衔与级别）进行管理，是我期待的技术管理氛围。

QCon：您要在 QCon 分享的话题是《构建可伸缩的软件开发团队》，可否先剧透下为什么要分享这个话题？会有哪些要点？想带给参会者什么样的思考？

李智慧：上半年翻译了一本书——《 Web Scalability for Startup Engineers - Tips & Techniques for Scaling Your Web Application 》, 中文译名暂定为《互联网创业公司工程师指南： 构建可伸缩的 Web 应用》，预计会在下个月由电子工业出版社出版。这本书最后一章主要讲述创业公司技术团队如何随着业务伸缩快速重构，以适应业务和公司的变化，当时我自己管理的技术部门也正面临这样一种情况，所以感受颇深，希望能够借这次 QCon 的机会，和大家交流探讨一下关于加班、技术团队组织、技术管理，以及工程师文化。欢迎大家到时交流指正。

QCon：期待您在 QCon 上海 2016 上的精彩分享！

是不是想一探究竟，与大咖面对面交流？“面咖”门票，即将售罄，机不可失，欲购从速！
获取 QCon 最新消息，第一时间观看演讲视频，欢迎关注 QCon 微信公众号。