靠谱 CTO 必须是技术高手？前 Facebook 总监：技术越好，bug 越少

技术管理者也需要全能。

作为科技界广受赞誉的杰出管理人才，前百度集团总裁、Y Combinator 中国创始人陆奇在接受媒体采访时，曾谈到管理具备穿透力的关键在于自己要有相应的专业能力，“我以前要求自己做到的是，我手下两层以下的人，他们每个人的工作我都能做。这样整个公司里，没有人敢欺骗你、忽悠你。这个非常重要，大部分企业中层都在忽悠高层，资源其实是浪费掉的。”

在陆奇的逻辑里，管理人员至少要能随时接管比自己低二个级别的人手上的工作，这就要求管理人员必须是专家中的专家，清楚工作的每一个细节。也就是说，一个真正强大的管理者，是绝对不应该凭借所谓“管理能力”做到领导的，特别是技术管理人员，有代码实操能力，保持对一线业务敏感，也是优秀领导者要具备的能力。

然而对于“IT 领导者应该是位出色的工程师”、“CTO/VPE（工程副总裁）应该具备怎样的技术水平”这一类的话题，总是存在一些争议。

乍看之下，很多人可能觉得这问题有点莫名其妙——首席技术官和工程副总裁不都是技术人吗，没两把刷子还能当技术主管？但实际情况就是有不少 CTO/VPE 虽然在自己的岗位上做得相当出色，但技术水平却不是很突出。

这也是很多科技企业领导班子的一个奇怪之处。工程团队在每个成长阶段都会建立起新的管理层，把负责人从实际技术工作中抽离出来。这种制度的问题是一方面强行要求优秀的员工在管理和技术中二选其一，另一方面迫使很多技术超强但管理思维不足的候选人因未能晋升而失望离职。

马斯克在今年也曾发布一条 Twitter，表示深信技术领域的管理者必须具备优秀的技术能力，领导软件开发的人也需擅长写代码。这个说法深受一线开发人员赞同，但马斯克照样也收到了一些管理者的强烈反对，评论中有人认为管理能力和技术能力不是一回事儿，一个人是不可能同时掌握好这两种能力的......

最近，又一篇评论“CTO，也该是技术人”的文章在 Hacker News 上被顶上了“热搜”。

作者 Aditya Agarwal 与马斯克的观点很一致，认为技术管理者必须具备过硬的技术能力，甚至是代码能力。

Aditya Agarwal  拥有卡内基梅隆大学的计算机科学学士和硕士学位，是 Facebook 的首批工程师之一，他帮助构建了 Search、NewsFeed 和 Messenger 等关键产品的第一个版本，随后成为 Facebook 的第一任产品工程总监。也曾作为 Dropbox 的首席技术官和工程副总裁，将 Dropbox 工程团队从 25 人扩大到 1000 人，领导并负责 Dropbox 新产品开发、基础设施和技术运营多个方面的工作。另外他也是硅谷初创公司的投资者和顾问，是一家筹集了 5000 万美元种子风险基金的创投企业合伙人。

在文章中，他表示领导者的技术水平与员工水平是直接挂钩的，并以跟踪和解决 bug 为例，讲解了深厚的技术能力如何成就卓越的工程领导者形象。

同样的，他的观点激起了很多讨论，包含一线研发和 CTO，尤其对于解决 bug 这种能力，大家非常有分歧。

一些持赞成意见的讲道：

CTO/VPE/工程总监候选人应该通过编码面试。事实上，他们应该更出类拔萃。

我曾在一家公司工作过， CTO 是一位非常有才华的开发人员，他可以跳入混乱的境况中快速解决问题。从本质上讲，他的头衔是“CTO”，但实际上这意味着他是一个超级管理人员，可以解决他想要解决的任何技术问题，而无需向任何人报告。

一些持反对意见：

“技术开发”是一项全职工作。任何“高于”你的职位的人都能够完成你的工作，这个想法不仅是荒谬的，也是对工程师的侮辱。CTO 应该能够就技术问题进行高层次的对话，但期望他们能够编写代码是不现实的。

我认为让经理深入技术细节是没有必要也没有作用的，他们应该关注于人的“管理”。

如果 CTO 专注于软件错误，则会出现更大的问题（比如人才密度过低、产品优先级低等）。

我曾经以首席技术官的身份插入代码工作，结果反而适得其反，因为他们觉得这是缺乏信任的表现（我认为是这样，但当时我没有意识到这一点）。

......

我们将 Aditya Agarwal 的文章翻译了出来，如果你有类似的经历和自己的看法，欢迎留言评论：

CTO 必须是技术高手吗？

CTO 需要在项目冲刺阶段参与开发，跟同事们一道加班加点写完代码吗？他们有必要扮演系统“首席架构师”的角色吗？VPE 要不要拥有出色的技术洞察力？或者说，在这样一个以管人为主的岗位上，其实没必要对技术和技能提出过高的要求？

其实是应该有所要求的。企业技术高管应该保持自己技术水准的主要原因，有以下五点：

1. 没有卓越的技术能力，CTO/VPE 根本无法成为合格的质量评判者——至少无法在优秀与优秀之间做出区分（涉及工程师招聘、系统设计等层面）。

2. 有了优秀的技术水平，他们才能在质量、速度、发布日期、功能权重等问题上做好良好权衡。而做出正确权衡，正是伟大领导力的核心表现之一。

3. 让高管赢得整个团队的尊重。技术人都有一颗比较的心，如果领导者自己都做不成某件事，那员工们就不会把你的意见太当回事。他们可能会往旁边一站，摆出一副“你行你上”的态度。

4. 还有个更微妙的原因：技术高手往往对技术有着浓厚的热情，想要突破一个个可能的极限。只有具备这样的驱动力，管理者才能激励团队、带领同事们走向卓越。技术领导者身上的热情能让平凡的任务化腐朽为神奇。他们不只将技术视为达成目标的手段，更对手段本身产生了认同与共鸣。拥有此种特质，才是真正的前瞻性管理者。

5. 最后，正所谓英雄惜英雄，高技术领导者更容易吸引和招募其他技术高手。伟大的工程师不愿屈身于纯管理者之下，而是希望顶头上司能够理解他们的出色之处。所以，领导者的技术水平往往与员工水平直接挂钩。

与 Bug 的永恒之战

下面我们从具体整合出发，聊聊在与 bug 的永恒之战中，深厚的技术能力如何成就卓越的工程领导者形象。

任何软件都永远摆脱不掉 bug 的阴影，残酷的现实就是如此。这种对抗可以胶着、可以缓和，但永远不可能彻底胜利。而企业中工程领导者的一大责任就是在开发新功能（大家都爱新功能）跟维持质量/消除 bug 之间找到平衡点。也就是说，技术领导者必须以截然不同的激励措施分别面对产品与销售团队间的需求冲突。

首先要明确一点，如果无法衡量、则无法改进。因此，针对 bug 的第一阶段作战计划就是先衡量现有产品的质量是什么水平。如果非要说，还有个第零阶段，就是定义什么是质量“好”。

这就要回答一个产品层面的问题：在我们的应用程序当中，用户最关注的前两、三项指标是什么？最终得出的答案，就是我们必须全力保障、使其始终正常运行的核心。

以 Dropbox 为例，这家公司的宗旨就是存储在平台上的用户数据永远不会丢失或损坏。毕竟任何数据访问故障都会破坏 Dropbox 这个品牌的核心价值。作为存储服务商，Dropbox 只要弄丢一个文件，供需双方间的信任将彻底消失。其他的当然也很重要，但这种可靠性永远是第一位。

在 Facebook，衡量质量的关键是保证在应许的地域和不同网络条件下始终提供快速稳定的页面/应用程序加载速度。如果无法快速浏览 Facebook 页面，很多用户就会失掉耐心、选择退出。

第零阶段讨论完成：为产品制定清晰的、包含上下文信息的质量定义。

正式进入第一阶段，通过这项定义做出准确衡量。这事听起来容易，但也不可能一蹴而就。虽然市面上已经有很多优秀的数据工具，但根据个人经验，正确的内容配置和设定还是需要漫长的探索和调整。最初难免要出点错误（例如低质量数据），但请千万坚持到底。

这里给大家分享一点具体建议，就是每周或每月组织一次质量指标审查，借此了解事情的发展趋势。在此阶段，我们唯一的目标就是提高对衡量指标的信心。

在建立起信心之后，接下来就要设置一条不可触碰的质量红线。这就是第二阶段，也是工程领导技术能力的集中体现。CTO/VPE 必须深入理解这条红线该设置在哪里，逼近红线时会出现哪些危险信号，还有远离这条红线需要做出哪些努力。

CTO 需要向团队成员明确表达：一旦质量低于某个点，那么所有工作都要暂停，专注于将质量拉回正轨。但这势必会导致摩擦，特别是跟产品主管和 CEO 的摩擦。没人喜欢开发延迟，我们更重视质量，但他们可能更重视上市速度和投资回报。不过这就是技术主管必须贯彻的切实纪录，而强大的技术能力可以让我们的评估结果更受公司内其他高管的信任，降低这项纪律的执行门槛。

再来聊具体例子：随着 Dropbox 工程团队的不断壮大，加上对 Dropbox 桌面客户端代码库的持续更改，我们发现的 bug 数量也在迅速增加。而考虑到大多数用户都会通过桌面客户端作为存储文件的主要访问方式，那这就是我们的服务红线，绝对不能打破。

总是是，我们的桌面客户端代码库并没有随着全体工程师的开发过程而扩展。虽然一直能够勉力维持，但深入研究技术架构之后，我们发现原本的工作习惯离红线太近了。我们最终得出结论，只有通过重建架构，我们才能在稳定支持后续扩展的同时、让 bug 修复变得更加轻松易行。唯一的问题，就是整个重构过程大概需要 6 到 9 个月。

这时候，我们就要告诉 CEO，拿出时间投入到核心产品的根本性优化当中是必需的。把这部分延误视为计划内部分，凭借出色的技术能力获取公司领导层的信任，把握住推动技术变革的主导权。

我承认，速度对于初创企业至关重要。作为一名工程师，我在 Facebook 工作时就经历过快速行动、打破常规的内部变革时期。但 CTO/VPE 必须挺身而出，告诉大家什么叫“磨刀不误砍柴工”，什么叫先慢下来才能全力冲刺。出色的技术能力不仅能让我们自己对这一关键判断更有信心，也能更好地感染并影响到企业内的其他同事。

接下来就是 bug 之战中的第三阶段。在重建桌面客户端架构的过程中，我们在各个路线图/OKR 规划过程中不断提高质量标准，将红线拔得更高，并随着时间推移和实际情况持续调整产品质量与红线间的距离。

第三阶段完成之后，我们就有了一个持久且稳定的流程，能够保证核心产品长治久安。

我听说过不少 CTO/VPE 技术能力受到质疑的情况，大多是因为这类高管职位要由企业 CEO 和创始人亲自面试，所以过程中往往缺少编程测试这个环节。

这里我简单提一点：CTO/VPE/工程总监至少得能通过编程测试，甚至应该拿到一个很高的分数。

当然，候选人的管理技能、与创始人/同事们的合作能力和招聘能力也很重要，但他们也必须顺利通过编程测试和详尽的系统设计考察，毕竟这才是技术领导者的本分。

总而言之，首席技术官也应该是技术人、必须是技术人。

参考链接：

https://blog.southparkcommons.com/your-cto-should-actually-be-technical/

https://news.ycombinator.com/item?id=32987094

https://news.futunn.com/post/4604869?level=1&data_ticket=1664251591162541

https://www.linkedin.com/in/adityaagarwal3/