本月你还剩 1 篇文章可阅读，之后需要 注册 一个免费的 LeadDev.com 账户。

预计阅读时间： 10 分钟

要点总结

  • 没有单一的 CTO 职位。这个头衔涵盖从仍在编写代码的创始人，到多年未打开编辑器的面向董事会的执行官。
  • 首先是高管，其次才是技术专家。你负责技术与商业成果之间的联系。工作主要是对外和横向的，而不是深入到代码中。
  • 2026 年，标准在两个方向上都提高了。更具战略性，也更具实操性。

在几乎每一个 工程职位 中，你的同事都是其他工程师。无论你是初级工程师、资深工程师，还是 工程经理，你都与做类似工作的人共处，并不断依靠他们来验证你的想法并分担工作量。让我对担任 CTO 感到惊讶的第一件事是，这种情况不再成立。

我的团队不是工程团队。我的团队是其他职能领导者、CEO、CFO，以及负责销售、产品和市场的人，我们共同运营公司。这个群体与 工程师团队 完全不同，而学会融入其中正是这份工作的核心。

所以当有人问我整天在做什么时，答案是变化非常大。一个小时我可能在进行架构评审，深入研究一个项目；下一个小时我可能与财务部门讨论预算预测；之后我可能又在处理托管成本，或被拉进一次事故处理。这就是从技术角度看待整个公司的广度，而其中很少有工作看起来像我晋升前所做的那份工作。

升级后的收件箱。

接收每周工程洞见，提升你的领导力。

CTO 角色没有单一版本

CTO 角色从外部被严重误解的原因在于，它并不是一个单一的角色。在一个 12 人的初创公司中，CTO 通常是仍在编写大部分代码的创始人。在大型企业中，他们可能是一位面向董事会的科技高管，多年未提交过一次提交。

两者都正确地履行了职责，因为这份工作的核心是成为公司在其特定阶段所需的技术领导者，而不同阶段差异极大。

公司规模越大，角色就越倾向于董事会管理、资本配置，以及通过其他领导者来领导，而不是直接接触代码。越接近初创公司一端，角色就越倾向于相反的方向。然而，无论你处于这条线的哪个位置，责任是相同的。

那么我自己的角色是什么样的呢？Nordhealth 是一家上市公司，但在规模和轨迹上更接近于一家规模化阶段的公司。我像创始人型 CTO 一样运营我的角色，深入参与产品和技术决策，而不是从上方观察。

作为 CTO，你负责公司技术与其商业未来之间的关系，并向 CEO 和董事会负责。Camille Fournier 对此的简要描述是，CTO 首先是高管，其次才是技术专家，而当人们将这个角色想象成大楼里最优秀的工程师，位于技术阶梯顶端时，往往会忽略这一点。实际情况完全不是这样。

然而，这种责任对我产生的影响与大多数人的预期相反。对一切负责让我想要更接近工作，而不是更远离它，而我已经将角色构建成可以做到这一点的样子。我希望建立一个追求真相的组织，而在科技公司中最真实的东西就是我们正在编写的代码，所以我保持靠近它。

这就是我们周三评审的目的，也是我坐在每个项目的 Slack 频道中，并使用 AI 来审视我们自己的代码库和日志，询问为什么某些东西很慢或如何更好地构建它的原因。保持技术能力是我知道质量标准得到维持、我们正采取正确方法的方式，也让我与每位工程师保持直接联系，我认为这是非常健康的。

一周的大部分时间都与他人打交道

由于工作是高管性质的，大部分工作 发生在与非工程师的对话中。我向 CEO 汇报，因此我经常与他交谈；我几乎每天都与产品 VP 交谈，通常每隔几小时一次。销售、市场和入职的 C 级同事会占用大量时间，客户也是如此，既要解决他们的问题，也要了解他们接下来的方向。我自己的工程领导团队只是本周的一次会议，而不是会议的中心。

我试图给每週一个有意的形状，因为如果放任不管，它会被会议完全填满。我们为研发团队安排了两个无会议日——周二和周四，这保护了团队和我两天的深度专注时间。

周一安排我的 一对一会议 和我们的高级领导会议，这通常会产生一份长长的待办事项清单。周三是项目评审，CEO、产品 VP 和我与负责项目的人一起坐下，查看最新构建、给出设计批评，并解锁卡住的决策。

周五我给整个部门写信，因为在这个规模下，写作是你能触达比你能直接交谈更多人的方式。

这种结构极大地帮助我应对上下文切换和高工作量，因为我总是知道自己有两天专注时间来完成工作，所以即使在其他日子里不断被打断，我也不会感到太大压力。

更多相关内容

没人教过我的技能

你的 技术技能 被视为理所当然，这也是你最终成为 CTO 的原因。然而，我必须学习的技能，也是我最鼓励任何有志于此角色的人认真对待的技能，是阅读公司财务。

它教你看到一个决定的真实成本，而不是它的标价。令人不安的是，最佳的工程答案和最佳的财务答案往往指向不同的方向。工作很大一部分是成为负责在两者之间找到正确权衡的人，并向可能倾向于另一方的人解释这个选择。

理解事情的成本，或未来可能产生的成本，在工程领域被严重低估，部分原因是组织结构常常让工程师无法看到其决策的真实美元成本。

以我们的一项决策为例，它表面上看纯粹是技术性的，而且我们第一次做错了。我们根据早期使用量估算将监控放在托管的 Grafana Cloud 上，并享受无需自托管的理想状态。

随着我们增长并更清楚地了解我们实际想存储多少数据，这种定价模式不再适合我们，继续使用的成本正走向我们无法接受的方向。所以我们现在正在迁移到我们自己托管和运行的版本，并在合同到期时构建切换。

工程师的本能是继续支付供应商费用，让实施团队专注于产品工作，但财务问题是这种选择在你实际所处的轨迹上真正花费多少，而不是你最初建模的轨迹。

自己运行也有真实成本，包括构建和运营所需的工程时间，所以工作是用长期心态诚实地权衡两者，而不是在本季度选择较少工作的一方，并将余下的推给未来。让我们做出决定的因素是完全的财务控制和零意外，因为自托管让我们决定在快速的近期存储和廉价的长期存档之间保留多少，因此成本曲线是我们随着持续增长而塑造的。

这个轶事很好地描述了这个角色对你的要求：停止成为拥有最佳技术答案的人，成为碰巧拥有技术的公司运营者。你可以在组织的任何层面练习这一点。在任何人授予你预算权限之前，赢得技术争论的方式越来越多地是用成本和对公司的承诺，而不是技术优雅的语言来表达。提前进行这种思考是值得的。

AI 如何改变 CTO 的工作

AI 在过去几年中比其他任何事物都更改变了这一职责。我推动整个部门每天使用它，我们现在大部分代码是由 AI 生成的，而不是手工编写的。我们目前主要使用 Claude Code，其次是 Cursor 和 Codex。

然而，更大的转变发生在整个公司，我们正在教所有人，而不仅仅是工程师，自动化他们工作周围的工作，而我对此有很大投入。

尽管行业仍在 努力准确衡量 AI 的收益，但对我来说重要的是结果，这已经是具体的。我们不再知道单个工程师能产出的上限，我们正处于探索之旅，看看我们能用现有工具以高质量完成多少工作。

同样的财务视角改变了我对招聘的看法。一位新工程师绝不仅仅是一条薪资线。一旦你计算角色周围的一切，这是一笔数倍于该数字的承诺，难以逆转，而且你是在根据去年对一个人能产出多少的假设做出决定，而此时 AI 正在改写 这些假设。

所以今年我与我们的执行团队和工程领导达成了一项不同的默认协议。我们将座位数固定在一个不变的数字上，并开始探索如何用现有的人尽可能高效和有效。如果有人离开，我们会让座位空置大约三个月，然后才开始讨论补位的问题，只有在真正需要时才招聘。

重点从来不是节省的钱；一个硬性的限制是我发现唯一能可靠地促使更好行为的方法，即思考是减少范围还是找到更聪明的方式解决问题，而不是默认寻求更多人手。

在不受约束的公司会招聘去同时追求所有事情的地方，我们必须对我们承担的新功能和新市场数量保持有意的限制，并对我们原本会构建的好想法说不。这种约束让组织更深入思考，而不是仅仅花费更多，我认为这样做是非常好的实践。

LeadDev Berlin promo

柏林 • 2026 年 11 月 9 日和 10 日

工程领导力从未如此快速变化。
在 LeadDev Berlin 看看其他领导者如何跟上步伐。

比看起来更难的部分

这份工作最难的部分是我一开始提到的。你是工程树的最顶端，这意味着你不再有一个自然的工程师团队可以依靠。

最重大的决策，那些关于人员和金钱的决策，正是你不能总是与受影响的人讨论的，而大楼里没有同级在你的确切位置，面对你确切的问题。

我发现处理它的唯一方法是建立一个你信任的专业人士网络，一些在公司内部，大多在公司外部，这样最难的决定在你独自做出之前就能在某个地方得到检验。

进入 CTO 角色很难，除非你自己创办公司，而这远不止是成为一名优秀的技术专家。你必须想要成为一名公司运营者。如果这是你想要的道路，那么要像你曾经对技术一样，对商业和你的行业充满好奇，因为这是这份工作没人宣传的那一半。

我单独写过 我通往 CTO 的曲折道路，我没料到的是它会如何改变我的动机。如今我更关心打造一家伟大的公司，而不仅仅是构建一个伟大的产品。