招聘顾问眼中的 CTO 悖论：想做的做不好，能做好的不爱做
本文作者 Paul Robinson 曾经做过 5 年的 CTO 招聘咨询顾问，也曾经在几家公司做过 CTO ，对于如何成为 CTO 以及如何招聘到优秀的 CTO ，他给出了自己的意见。
首先，有句话我不吐不快：
以前是缺好的软件工程师，而现在则是缺好的 CTO ，以至于在一周之内就有 3 家公司来向我咨询怎么才能找到优秀的 CTO 。我在想，是不是当承包商（ contractor ）给的钱太多，以至于没人想循规蹈矩，公司高层都招不到人了？
（译者注：在北美，由于累进税制，对于年薪 8 万刀以上的员工而言，为了少缴税，最好的办法是成为承包商，即 contractor ：开一家只有自己一个人的公司，把自己当做派遣人员派遣到原公司，原公司和这家单人公司签派遣合同，自己给自己开工资。这样的好处是缴税少，而且可以将自己家的日常开销当做公司支出报税，进一步减少税额。然而缺点在于，公司可以随时解除合同，员工不受劳动法保护，没有福利，需要自己处理医保养老金税款缴纳问题。具体涉及的法律问题在美国需要按州进行个别讨论，加拿大的劳工法与美国不甚相同。译者不是法律专业人士。）
工程师（特别是小型公司的工程师）会觉得 CTO 就是年薪很高的工程师，并且领导着整个公司的技术方向，是“超级技术领导”。
在我担任 CTO 时，我做了以下这些事情：
和商业部门大佬（ CEO 、董事会、投资人等）沟通，确定接下来几个月的路线；
和产品经理、分析师研究出可行的产品路线图，和商业规划匹配；
按照产品和商业路线图规划技术路线图；
当某个路线技术上不可行时，劝说其他人放弃这个想法；
设计自己的开发团队；
在功能、BAU 和技术债 / Bug 间找到平衡点，最大化商业利益；
关注技术开发涉及的合规性问题和法律变动；
准备并申请开发预算 —— 工资和研发预算一般是两条线；
准备并申请运行预算，例如硬件、服务（数据中心、云服务等）、专利授权等；
把上面所有涉及的工作，用财务数字和管理层、董事会讲明白；
把上面所有涉及的工作和投资人讲清楚，而且留后手以免被出局；
建立技术团队的文化；
把所有事情用技术语言和技术团队说明白。例如，对董事会汇报可以说：“本司预计于 18 ~24 个月内由 CAPEX 模型迁移至 OPEC 模型”，但是对技术团队你得说：“接下来一年到一年半我们要从自建机房全部迁移上云”。
保证技术团队的运行不受阻碍。你可以对人大喊大叫，但是大部分人觉得大家互相信任，不需要管理的效率最高；
招聘高级别技术员工；
管理、指导并支持技术高层；
考虑薪酬，期权管理等；
开除员工，不能心慈手软。有人告诉我一条金科玉律：用目的评价人，而不是结果。尽可能不开除好心办坏事的人，并想办法帮他们；
做有争议的决策后把故事编圆，保证团队看起来团结一心；
当团队做得好时，激励他们；
出任何差错你去承担。如果你拉不下脸，就别进管理层。
你也许已经注意到了，作为一个 CTO， 我写代码的时间并不是很多。但不同的公司有不同的情况：在小公司，你必须自己亲力亲为做产品。而在大公司，你根本没有时间亲自做产品。
我在上一次进行 CTO 演讲时笑称：我司大到我不需要写代码，但又小到我必须亲自写，搞得我两头不是人。
虽然 CTO 的职责相通，但还是分不同种类的。一般来说，CTO 可以分成“运营管理”型，和“技术领导”型两种，而这两种 CTO 的背景和角色的区别是巨大的。
我曾在伦敦中心的高级酒店里参加过一场咨询公司的 CTO 酒会。酒会过后，为了听取更多技术领导人的看法，他们举办了一场“圆桌会议”。在这场“圆桌会议”中，我发现了一个让我很震惊的事：在到场的 20 多位 CTO 当中，曾经学过代码的 CTO 只有两名，其中就包括我。
其他的 CTO 觉得有技术背景的人很奇怪，他们会说：“都要当 CTO 了，为什么还要学写代码？”
看到这里也许你会觉得奇怪：难道 CTO 不是从工程师一层层升上去的吗？
很遗憾，并不是。
曾经和我共事过的几名 CTO ，他们都写过一两行代码（几行 COBOL 的程度），但最终他们还是会在开始研究管理职务后跳槽。
而更多的情况是从运营或产品经理升上去的，因为大家觉得他们能够很好的理解技术，于是就把技术团队交给他们领导了。
当然，对于想成为 CTO 的工程师来说，上面所说的只是万千条路的一种。还有很多工程师类型的 CTO 职位，会更像“技术领导” —— 技术领导更多时候是要以身作则，是当高级工程师在不确定如何最好地解决问题时所面对的人，并且能够让他们相信这是最好的技术解决方案的人。
但并不是所有公司都需要这种领导，有些公司也会让技术团队自己研究方案。但当他们真的需要技术领导出面，而 CTO 又没技术能力的时候，整个公司有可能会直接死掉。
我认为，技术领导者最适合纯技术公司 —— 公司的主要产品就是技术，例如软件、B2B ，或者卖科技产品的公司。这种公司的 CTO 必须是理解整个产品的工程师，而且是有同理心，可以领导团队的人。
我的第一份技术工作是一家运营商公司。当时我的 CTO 熟悉 Unix 命令行，会用很多种语言写代码，并且可以直观地将模式规范化为 3NF 。后来，那家公司被收购，并且大幅发展，现在已经成为了欧洲最大的运营商之一。一两年前，我看了一次他们现在 CTO 的采访，很明显他对工程的错综复杂知之甚少。
所以，一家公司所需要的 CTO 可能会随着时间的推移发生变化。 这意味着你要么改变角色，要么走人（从一件合适的衣服转移到另一件相似尺寸的）。后一种模式的适用范围更大，因为在更小的公司，技术领导更受重视。
总体来说有以下 6 点：
CTO 的职位在不同的公司意义不同，职责也不同；
大多数工程师都不知道这个职位不需要懂技术，而自己又不懂运营和管理；
非技术人员又不懂工程师每天都在做什么，所以做不出技术决策；
随着公司在规模、功能上的发展，CTO 也要改变；
CTO 如果搞错形势 / 态势，就得下台。同时，CTO 想跳槽也不容易，因为不是所有公司都有 CTO ；
CTO 很少像其他 C-suite 职位那样得到丰厚的报酬。
所以我觉得不是因为大家都想当承包商，造成 CTO 难找：大家心里像明镜似的。如果你是高级程序员，考虑当 CTO ，那你肯定会认识 10 年前改行当 CTO 现在痛不欲生的朋友。
简而言之：想做的做不好，能做好的不爱做。
那我们该怎么办？有一个办法是：创立一个类似于 CTO 的职务，但不是像工程总监、工程副总裁，技术总监这种我们耳熟能详的职位。这些职务在不同的公司意义不同，但是我希望以后会慢慢的稳定下来。
我也见过 CTO 做纸上工作，技术总监做技术工作，但大都效果不好，因为他们都有管理背景，却又都不想搞技术，我认为这都是因为管理层没有人理解技术领导所需的技能造成的。
招聘 CTO 的建议
如果你想招聘 CTO ，好好考虑一下你需要的技术和背景；
如果你的团队需要技术领导，那么找一个高级工程师，给他时间和空间熟悉非技术工作。帮助他，明确说明你需要 CTO 做什么；
如果你的团队需要运营管理，那么找一个有运营背景的人，让他找一个技术总监，并明确他们的责任分工。
仔细想想你想得到什么，以及你想成为什么样的 CTO 。 你可能更喜欢工程总监，甚至只是一家大公司的技术主管。
但万事开头难。多问问题，寻求帮助，虽然这会让你感觉筋疲力尽，但如果一切顺利，你会为你的团队和同事感到骄傲的。
最后叮嘱一句：了解领导和管理之间的区别，知道何时用什么。
原文链接：https://hackernoon.com/the-problems-of-the-cto-role-c2a143a1cec7