导读：近期业界有大量有关什么是一个好的 CTO 的讨论，本文是最近一周在美国码农圈热议的文章，高可用架构翻译转载如下。
如果你还在整天写文章辩论 PHP 是***的语言，那说明你还没有成为一名真正的 CTO。
CTO 并不是团队中最疯狂的黑客，编写代码是 CTO 最不重要的工作。 在我看来， CTO 是一个能够与其他技术人交流技术并引导他们更好的完成项目执行的人。 另一方面， CTO 是一个保护技术团队免受外部干扰的人，并勇于在需要时承担错误责任的人。
在很多缺乏技术人员的创业公司里，成为 CTO 并非难事。然而 CTO 在这样的公司里，很大程度上只是这个公司严重过度疲劳的码农。我主要想讨论 CTO 这个位置需要什么样的能力，并且如何养成这样的能力。
我讨厌技术部门只是实现了他人所设想的功能。 这样技术部门与其说是公司的部门，不如说是一个技术外包团队，因为它独立于决策过程。 正如 Camille Fournier 在“ CTO 的作用”一文中所说，“ CTO 必须保护技术团队不要成为一个不表达自己的需求和想法的纯执行部门。
如果公司需要一个 CTO，那么这个人定义了对技术的长期影响的愿景。现在越来越多的企业不是使用技术，而是被技术定义。现代的一切都是建立在技术的基础上，从零售电子商务到移动应用程序，当有人从内部推动技术发展的时候，公司就会因此获益良多。 CTO 不能让技术团队仅仅成为实施者。
我曾经和不少 CTO 讨论过关于如何让公司的其他部门尊重技术开发的过程。例如，如何推广单元测试。我会告诉他们：“这是我们要走的方向，这就是它将如何工作。”
总之，无论 CTO 说什么，就应该做成什么样。如果 CTO 没有这样的技术决策权力，那他就不是 CTO，而是工程师小组长。
CTO 是一个业务战略的工作，它定义了公司内部的技术方向。如果你讨厌会议，讨厌跟非技术人员交流，并认为所有经理都整天坐在一起，什么都不做，那 CTO 可能并不适合你。任何会议都是关于公司业务发展方向的讨论，以及技术如何能够帮助达到目标，或者有时技术如何为增长创造新的机会。
因此， CTO 必须了解企业和客户的需求。从我的经验来看，很多技术人员喜欢远离“商业的东西”。然而，作为***技术官，这却是***要事。技术决策不会在纯粹的软件或硬件问题中产生。大多数时间 CTO 应与产品经理同步，以保证产品战略与开发进度一致。
最终， CTO 会创造一个允许团队做牛逼事的环境。现在很大的问题是找不到足够的工程师，每个公司都在寻找工程师，高质量工程师从来都很少，因此一个好的环境很重要。 CTO 应该知道如何构建好的环境，因为他们曾经是其中之一。如果团队想要做 TDD，或配对编程或临时服务器， CTO 都应该批准。由工程师来衡量这些变化带来的影响。
思考技术研发的财务影响也很重要。一个创业公司可能允许自己使用***最酷炫的技术，而一个更大规模的公司则多半不会如此选择。这一切都应该在投资回报的基础上权衡，看看它给客户带来多少价值。因此，在大多数情况下，它是关于现有优势和更新已有的基础设施的平衡，而不是花费大量精力去做很难实现的工作。根据 80-20 规则，找到能通过 20% 的投入获取 80% 的回报的那部分工作。
我曾经对未来的 CTO 候选人进行过访谈，他们会问：“为什么你坚持这个老版本，为什么你没有用 React.js 重写?”
对不起，我认为这不是一个好主意。有时候，老的遗留程序确实更难管理，但是重写几乎总是为客户提供不了价值。
CTO 需要平衡团队力量，好钢用在刀刃上。建立一个只想要触摸新技术的团队是不可持续的。
构建一个阶段来实现你最重要的事情。例如，我认为可靠性和安全性是任何软件的两个最重要的功能。因此，业务目标的任何变化都与之相称。对于一个非技术人员来说，掌握安全相关的知识显然是不可能的。然而这样很可能会导致公司追求的目标会侵犯别人的隐私(安全性有问题)。 CTO 的工作的一部分是处理这个，并确保他们不会犯错。
虽然我做的是技术，但是我认为技术应该是用户不可见。 PHP 是否是***的语言，对于很多开发者是一个令人兴奋的话题，但对于一个组织(公司)却不是。我相信， 不关心这类事情是成为 CTO 的踏脚石——不过分关注技术细节，而是寻找团队和其他一切。
成为 CTO 是关于实现更大技术影响的途径，如何定义业务和如何帮助客户。它有助于理解技术本身，但不仅如此。
