不懂技术的 CTO，不是好的 CTO

未有旳怀念

摘要：CTO，程序员职业发展的重要方向。不过，想到成为一名好的 CTO，不仅需要有技术前瞻性、优秀的管理能力、敏锐的商业嗅觉，更重要的是自身技术实力一定要够强。
原文链接：https://blog.southparkcommons.com/your-cto-should-actually-be-technical/
声明：本文为 CSDN 翻译，未经允许禁止转载。
3 p2 r9 \" x( M1 [作者 | Aditya Agarwal
译者 | 弯月 责编 | 苏宓
出品 | CSDN（ID：CSDNnews）
CTO/VPE 应该具备怎样的技术水平？你可能认为这个问题的答案不言而喻，CTO（首席技术官）或 VPE（工程副总裁）不都是技术人员吗？
然而，你知道有多少 CTO/VPE 不懂技术吗？这是现如今许多科技公司管理层普遍存在的一个怪异之处。工程团队的发展每步入一个新阶段，就会创造一个新的管理层，这些负责人是从实际的技术工作中抽离出来的。然而，这些人选必须能够胜任高层管理的任务，因此常常导致技术能力最强的候选人落选。
$ l3 P* ~+ A* q! Q$ bCTO、VPE 为什么要懂技术？
5 n8 a: Q) C2 Z' w5 _5 H这有什么问题吗？面对最后期限迫在眉睫，首席技术官也应该加班加点地写代码？还是担任系统的 " 首席架构师 "？VPE 是否需要具备出色的技术洞察力？还是说，我们本不应该要求管理层领导具备卓越的技术力？
- t6 b6 D5 H" M$ h* a$ x; g& g9 N当然不是。公司的技术领导者理应具备高超的技术力，主要原因有五个：
只有具备卓越的技术力，CTO/VPE 才有评判的资格，在招聘工程师、系统设计师等的时候，清楚地分辨出哪些人只是合格，而哪些人出类拔萃。
只有具备卓越的技术力，CTO/VPE 才能良好地权衡质量、速度、发布日期以及功能等因素，而做出正确的权衡是领导力的基石之一。
. g& p2 i7 G1 v只有具备卓越的技术力，CTO/VPE 才能赢得整个团队的尊重。如果 CTO/VPE 无法在必要之时身先士卒，力挽狂澜，那么就很难让员工信服。
, ?' c9 {0 s4 O: q/ v+ q" I; s掌握了高超技术的人往往对技术有着浓厚的热情。他们希望突破技术的界限。这些人能够激励团队走向成功。充满激情的技术领导者会让每个人充满使命感，即便面对原本平凡的任务也能全力以赴。在他们眼中，技术不仅仅是达到目的的手段，他们对这些手段充满了兴趣。只有这样的人才能站得高看得远。
/ r$ {1 G- P: H6 R: b" o拥有高超技术的领导者更容易吸引和招募到其他技术高手。伟大的工程师并不想为伟大的人事经理卖命。由于以上种种原因，他们更加希望为与他们能力相匹配的领导者工作。
Bug 之战
; H9 [3 H$ G: e' P9 N: {* Z0 F下面，我们通过一个具体的例子，说明技术力对于工程领导者的角色有何帮助。
软件中存在 Bug，这是万古不变的难题。逃无可逃，避无可避。程序员与 Bug 之战时而打得难解难分，时而略有缓和，但这场战争永远没有胜利的一方。公司的工程领导是平衡开发新功能与保持质量并消灭 Bug 的关键角色之一。这通常意味着，通过截然不同的激励措施，调节产品开发与销售团队之间的紧张关系。
6 ]# J" z* Z) b' z# ^那么，我们究竟该怎么办呢？
2 A+ N% I3 d& o( u  i如果你想改进某个方面，首先必须制定衡量标准。因此，Bug 可持续作战计划的第一步就是衡量当前的质量。当然，在这之前（也就是第 0 步），我们首先需要定义质量等级。
& X  K5 m7 o' ^( @  g3 s: Y7 s也就是说，我们需要回答这样一个问题：" 用户最关心的三大功能分别是什么？" 我们必须保证这些功能正常工作，而且质量上乘。
  m7 K; t( Y$ s$ I以 Dropbox 为例，这款产品的主要功能是确保数据永远不会丢失或损坏。同样，无法访问数据的行为也非常糟糕。它会破坏产品的核心价值。如果 Dropbox 丢失某个文件，那么这款产品的信誉就全完了。其他功能虽重要，但都是次要的。
. f: A5 N  a; S! ^6 }' f而对于 Facebook 而言，关系到质量的关键点在于，在广泛的地域和各种互联网速度下快速加载页面 / 应用程序。如果无法快速浏览 Facebook，那么用户就没有兴趣再使用了。
因此，第 0 步就是为产品定义清晰的质量等级。
2 H: x6 U1 ^! i1 G3 s+ L9 O0 x而第 1 步是根据我们定义的质量等级，准确测量产品的当前水平。当然这些工作无法在一夜之间完成。相关的数据工具有很多。但根据我的经验，正确配置和设置工具所需花费的时间往往会超出你的预期。而且刚开始的时候，你还会收集到错误的数据。但是，请不要气馁。
2 f, q2 G4 m" `( D$ b4 ]% o7 }" G面临这个问题，我们一般建议，每周或每月进行一次质量审查，以了解事态的发展情况。在这个阶段，你必须对自己制定的指标充满信心。
在跨越信心的鸿沟之后，下面我们就需要设置一条红线，确保质量不会低于这个范围。这是第 2 步，这时我们就能看到工程领导的技术力是多么重要。CTO/VPE 需要深入了解红线在哪里，以及如果接近红线将看到怎样的警告信号，最重要的是，为了远离红线，我们需要做些什么。
CTO 必须向每个人解释清楚，如果质量低于某个点，那么一切工作都必须暂停，并全力以赴提高质量。这会导致工作中产生一些摩擦，尤其是与产品领导和 CEO。没有人希望看到自己心爱的功能出问题或延迟。但你必须强制大家遵守这条规定。如果公司的其他领导者信任 CTO 的技术评估，那么遵守这个规定就会容易得多。
& \2 ^2 B8 K. b5 @' E4 ?下面，我们举一个具体的例子。随着 Dropbox 的工程团队不断壮大，Dropbox 桌面客户端代码库的变更也越来越多，然而我们发现 Bug 的数量也在迅速增加。桌面客户端是用户访问文件的主要方式，因此不能出问题，也就是说，这就是我们的红线。
问题是桌面客户端代码库并不会因为团队增加新成员而成比例地增长。深入研究技术架构后，我们发现这条红线距离我们的舒适区太近了。此外，我们还发现，重新组织架构后，修复 Bug 会更容易。但这种变更需要 6～9 个月的时间。
0 I' M! Y0 x- A/ y想象一下，你告诉 CEO，你需要这么长的时间来修改核心产品的底层架构，你们所需要面对的是重新组织架构期间造成的种种延误。整个公司的领导层都需要对推动这种变革的工程领导充满信任。
我坚信速度对创业公司的重要性。作为一名工程师，我曾亲身经历过 Facebook 快速行动、打破常规的发展时代。但 CTO/VPE 最核心的职责之一便是明白什么时候磨刀不会耽误砍柴。技术力不仅能让工程领导对于何时需要这种速度转变更有信心，而且还能将这种决策转达给公司的其他人。
" \) M$ _5 f; M" g" F在重新构建客户端架构期间，我们在 bug 之战中取得了重大进展：随着路线图与 OKR 计划的推进，质量标准也在不断提高。这是我们迈出的第 3 步，我们将红线移得更远，而且不会随着时间的推移再次被推回来。
& q' _. s/ a( q  s5 `最后一步，建立持久的流程，确保核心产品正常工作。
3 R" n% u; G( G+ x/ c如何招聘到好的 CTO/VPE/ 工程总监？
有关 CTO/VPE 的技术能力的讨论，我反复听到的一个话题是公司和创始人询问这些职位应当如何招聘。似乎有很多 CTO/VPE 候选人在编程面试中表现欠佳。
我个人认为，CTO/VPE/ 工程总监候选人应该通过编程面试。事实上，他们应该在编程面试中拿到优异的成绩。
1 @# R/ I8 [) J9 @+ [* F虽然这些职位需要具备管理人员的能力，并且能够与创始人和其他管理层通力合作共同管理公司，还要有招聘的能力，但他们应该通过编程面试，以及系统设计面试，而且技术力应该是决定他们能否胜任该职位的关键因素。
因为，首席技术官应该懂技术。