各位看官，今天又来了新问题。

CTO/VP应该具备怎样的技术水平？这个提问有答案吗？首席技术官或技术副总裁不用总是技术派吗？

当前在中国，企业研发部门 CTO/VP 有很多管理型的优秀人才，但他们在技术上未必都很好，这是许多科技公司管理层普遍存在的一个奇特之处。

软件研发团队的每个成长阶段都会新增一些管理人员，会把一些技术高手从实际的开发工作中调离出来担当管理角色，这不仅给管理层、领导者带来了选人的压力，也会导致技术能力最强的候选人浪费和流失。

这些和项目成败有关系吗？当然。面对迫在眉睫的上线期限，当前的首席技术官是否应该能够上手写代码？能否成为系统首席架构师？技术VP 是否需要具备较强的技术洞察力？或者，在与人员管理关联的角色中，能否估算技术能力是不是错误的？

很明显，一个优秀公司的技术领导者需要有很高的技术水平，其主因有以下五条：

1. 卓越的技术能力是 CTO/技术VP成为真正质量评判者的唯一途径——了解优秀与卓越之间的区别（跨越工程师招聘、系统架构设计等核心能力）

2. 技术水平使他们能够在产品质量、速度、发布日期、功能包含等做出良好权衡。而做出正确的权衡是强大领导力的基石之一。

3. 技术使技术管理者能够赢得整个团队的尊重。如果你不认为人们可以在计划中完成自己的工作，很难认真对待你的管理。他们只是卷起袖子应对你提出的修复而已。

4. 一个更奇妙的原因：技术能力高的人通常对技术有浓厚的热情。他们想法突破可能的界限。这些人能够激励团队走向卓越，充满激情的技术领导者会给原本平凡的任务带来积极的“眩晕感”。他们不只是将技术视为达到目的的手段，他们对这种手段感到兴奋，这些是一个有真正远见人物的标志。

5. 强有力的技术领导者更容易吸引和招募其他能力强的技术人员。卓越的工程师不想为只是一个人事经理工作。结合上述所有原因，他们希望为与自己能力相匹配的领导者手下工作。

下面再举一个具体实例，来说明深厚技术能力如何能支持研发领导者的角色。

你知道，软件中的Bug是永恒的存在，谁也跑不了。产品质量的战争只能打到胶着状态，缓和下来，但永远都不会胜利。

软件工程领导的关键角色之一是平衡开发新功能与保持产品质量与消除Bug。这通常意味着以截然不同的激励措施管理产品，如果公司还有销售团队，还要有与这些队友们斗智斗勇，化解需求。

再深入解释上述文字中讨论的细节。

“除非你开始衡量它，否则你无法改进它”。针对Bug的持续作战计划的第一步是开始衡量现在的软件质量有多好，而第 0 步实际上应该是定义好的结构。

这里需要回答一个产品问题：“用户在我们的应用中真正关心的前 2-3 件事是什么？” 这就是必须始终正常工作，并且质量高的东西。

在这里使用一个典型示例：Dropbox。这家公司的宗旨是：你的数据永远不会丢失或损坏。也就是说，任何无法访问自己数据的行为都很糟糕，它们会破坏产品的核心价值。如果用户在 Dropbox 丢失了一个文件，那么就信任而言，游戏很快就结束了。

其他好像都很重要，但和用户体验相比都是次要的。

再举例 Facebook，软件质量的一个关键部分是确保在广泛地理区域和网络连接速度上快速加载页面/应用程序。如果用户不能快速浏览，他将失去兴趣不再继续前进，导致价值流失。

因此，现在有了第 0 步：需要CTO技术负责人为特定产品制定清晰的、与上下文相关的软件质量定义。

接下来第 1 步是采用质量定义并开始准确测量。这通常不会在一夜之间发生，但目前已经有很多好的数据工具。根据经验，正确配置和添加相关内容需要比想象需要更长时间，也可能会有几个错误的开始（也可能是坏数据），但请不要气馁。

对于现在面临这个问题的人们，具体的建议是每周或每月进行一次质量评审，以便让团队人员了解并开放项目的发展趋势。

在这个阶段，技术管理者要做的就是对自己制定的目标充满信心。

一旦你跨越了信心的鸿沟，就可以开始设置一条质量上不能跨越的红线。这便是第 2 步，在这里我们看到了技术领导者的技术能力是多么重要。

CTO/VP更需要深入了解红线在哪里，你正在接近红线的警告信号是什么，以及最重要的是，实际需要怎么做才能远离红线。

CTO 必须让每个人都非常清楚，如果质量低于某个值，那么一切都将停止，必须专注于提高产品质量。

很显示，这也将导致部门之间产生摩擦——尤其是与产品经理和 CEO 之间。没有人希望看到他们希望的功能被延迟。但是这就是CTO需要坚定执行明确并且严格的纪律。

当公司中的其他领导者信任 CTO 的技术评估时，执行这一条纪律就要容易得多。

下面是一个具体的例子。

随着 Dropbox 的软件工程团队不断壮大，对 Dropbox 桌面客户端代码库进行越来越多的更改，人们发现Bug的数量正在倍数式增加。

而桌面客户端是用户访问Dropbox服务上文件的主要方式，它无法打破或被变。这也是一条红线。

当前问题是桌面客户端代码库并没有随着所有新工程师的工作而进行架构扩展。人们勉强扛过去了，但深入研究技术架构后发现，红线总是离舒适区太近了。它还清楚地表明，即使我们继续扩展，重构该架构也会更容易修复出现的错误，但这种重构需要 6-9 个月。

试想一下，告诉你的 CEO，你需要时间来对核心产品进行根本性的改变，要求解决技术重构所带来的所有延误。

这种情况需要整个公司的领导层对推动这种变革的技术领导层充满信任。

而速度对初创公司的重要性不言而喻。作为一名软件工程师，我在 Facebook 快速行动和打破常规的时代就开始了自己的努力。

但是 CTO/VP 最关键的角色之一是知道什么时候需要先慢下来，然后再快。技术能力使工程领导者何时需要这种速度转变更有信心，并有道德权威将其转移给公司的其他队友。

当我们重建桌面客户端架构时，团队在“解决漏洞之战”的第 3 步上取得了进展：在每个路线图/OKR 规划过程中不断提高质量标准。我们将红线移得更远，并使其有可能随着时间的推移不断优化。

最后一步，CTO将拥有一个持久的工作流程，可以让核心产品保持正常工作。

此外，我最常听到 CTO/VP技术能力价值受到质疑的情况，是当公司和创始人询问这些职位的招聘流程时。

一个令人震惊的数字让很多人低估了编程面试。所以我还是要说清楚：CTO/VP/技术总监候选人是应该要通过公司的编程面试。事实上的情况是，技术领导人应该达到出类拔萃的水平。

此外，还需要评审他的人员管理技能、与创始人和同事的合作能力以及他们的技术招聘能力。CTO 必须通过编程面试以及详实的系统设计问题，这应该是人才评估成败的关键部分。

因此，公司的首席技术官必须是一个技术人员。

作者：校长