CTO指南：欢迎进入责任的世界

当你第一次担任CTO职务时，你的世界会发生变化。你将承担许多新的责任，并需要关注新的事物。在这篇文章中，我想帮助你理解这个新世界。

我应该说明，我是从一个初创公司的CTO的角度来写这篇文章的，而不是从大型企业的CTO的角度——但这里的许多教训应该适用于任何情况。CTO也可能是联合创始人，在这种情况下，你将需要担心更多的事情。这篇文章是关于如何扮演CTO的角色，而不是联合创始人的角色。

我也猜测（尽管是一个有根据的猜测），你通往CTO职位的职业路径始于某种专家角色——也许是一名专注于特定技术栈（例如Java）的软件工程师。在职业生涯的早期，你的关注点很狭窄——你有一套非常具体的职责，所有这些职责都围绕着你被期望擅长的那一件事（例如Java）。在某个时候，你可能晋升到了一个更高级的技术角色——资深开发人员、架构师或其他类似职位，在这种情况下，你的专业领域必须扩大。你最初掌握的硬核技术技能仍然相关，但架构模式、数据库知识、网络和通信协议等也开始变得重要。你还需要更好地理解你所处的业务领域（例如，如果你开发保险系统，你必须了解保险行业的工作方式）。换句话说，你的世界变得更广阔了。

然后，在某个时候，你可能过渡到了某种领导或管理角色。当这种情况发生时，你的世界继续扩大——除了需要掌握广泛的技能（这些技能仍然相关，尽管你可能不是每天都会使用它们），你还必须学会如何领导和管理人员和项目。这又是另一套你需要学习的技能和需要理解的背景。

这一切都回到了“T 型”人才（或“通才专才”）的概念——一个灵活的技能集有助于你在职业生涯中取得成功。当你在职业阶梯上不断晋升时，每一级都需要掌握一系列新的技能，理解新的背景，并与新的利益相关者互动。你越往上走，就需要理解和/或担心的事情就越广泛。*

• 这并不意味着纯粹的恐惧——但你的脑海中可能总是会有一些东西在困扰你。这是好事；它意味着你在留心注意。

照片由 Andrew Neel 在 Unsplash 提供

作为技术团队中的个体贡献者，你有一套明确的责任，这些责任通常与技术或交付相关的目标有关。换句话说，你的工作重点在于功能组件——你构建满足某种业务需求的软件，你构建CI/CD流水线，或者你设计系统。最终，你做的是为他人（无论是客户还是其他开发人员）产生某种明确且可用的结果。

作为CTO，你的工作范围突然远远超出了仅仅交付有价值产品的功能性元素。这仍然很重要，但只是重要的一部分。作为高管，你不再仅仅负责在组织内部工作，而是要负责组织本身的发展。你的工作是建立一个能够构建系统的组织，而不仅仅是构建系统。

让我们来看看这具体包含什么。当然，我不能给你所有答案，因为这往往非常主观，并且取决于你的具体情境。但我可以提供一些指导，告诉你应该问哪些问题。如果你的组织规模较大，你可能需要担心工程负责人、CIO（首席信息官）、CISO（首席信息安全官）或CPO（首席产品官）的一些职责。

另外，你不能在所有时候同等关注所有事情——一天中的时间根本不够。情境决定了什么才是重要的。例如，如果你正在构建你的第一个MVP，而你还没有任何客户，你应该关注性能——但不是现在。

技术团队现在由你负责，但这不再是一个只属于你的团队。你不再是主要的技术人员，而是成为了一名高管。你需要建立和管理一个具备正确能力和获得适当支持的团队，以确保交付任务。这包含几个不同的方面。

照片由 Annie Spratt 在 Unsplash 提供

招聘

• 你团队需要哪些技能？ 如果你正在组建一个团队，你需要了解你期望团队能够完成什么任务？同时，还要考虑到领导能力和技术能力——这两个方面你都需要在团队中具备。
• 你在哪里寻找候选人？ 你可以通过猎头公司、直接发布广告、LinkedIn 或推荐来寻找候选人——这些选项都有相应的成本。推荐是一种很好的方式（好人通常认识其他好人），但要让这种方式有效，你需要创造一个让人引以为傲的环境，让他们愿意与朋友分享。
• 你如何筛选候选人？ 记住，如果你进行面试，这会占用其他工作的宝贵时间，而面试对象通常是相当资深的人——这也有相应的成本。你需要有一个高效的筛选流程。
• 你能提供什么样的薪资和福利？ 作为CTO，你可能并不总是能够直接影响这些——但你需要能够创建一个有吸引力的员工价值主张（EVP）来吸引合适的人才。

增长与留存

• 如何确保你具备所需的技能？ 如果你无法招聘新人，就需要提升现有员工的技能。在盲目地让所有人参加培训之前，你需要了解你需要哪些技能——然后根据这些需求制定培训和发展计划。培训不一定非得昂贵——如果你的培训预算有限，你可以为团队整理一份Udemy课程清单，例如。

• 如何与团队保持紧密联系？ 与直接下属的一对一会议，必要时与他们下面一层的人员进行交流，可以帮助你保持对团队情况的了解。随着你的角色变得更加战略化，你可能会逐渐失去对一些细节的了解——但是你不应该与团队脱节到如此程度，以至于陷入象牙塔。

• 如何解决团队表现问题？ 如果有人的表现没有达到应有的水平，你就需要处理这些棘手的对话。不要坐视不管，希望问题自行解决。如果有人每6到12个月才进行一次绩效评估，而这是他们第一次被告知存在表现问题，那么作为领导者，你已经失败了（参见文章末尾提供的资源，Kim Scott的《Radical Candor》一书对此有很好的建议）。

• 如何设定期望？ 如果你希望人们能够充分发挥潜力，他们需要知道你对他们的期望是什么。这并不意味着你需要正式、僵化的KPI——你可以根据具体情况决定什么是最合适的，但一定要确保人们知道你的期望。

• 你正在创造什么样的文化？ 作为CTO，你为公司技术团队的文化定下了基调。问问自己，你想要什么样的文化，以及如何创造它？我个人追求的文化是鼓励透明度和学习——人们不应该因为犯错而感到恐惧，当他们犯错时，应该能够讨论并从中学习。

在这里，我们回到在你的组织中管理一个部门的话题。流程应该使人们能够发挥最佳表现——既然你不是自己完成所有工作，从实际执行任务的人那里寻求意见是个好主意。一旦你定义了流程，确保这些流程对任何需要了解它们的人都是容易获取的。文档很重要。

照片由 Firmbee.com 在 Unsplash 提供

开发与软件开发生命周期（SDLC）

• 你的交付流程是什么，你如何定义成功？ 在现代组织中，这通常会以某种形式的敏捷开发来实现。然而，“我们是敏捷的” 是一个糟糕的过程定义。问问自己为什么你要遵循某个特定的过程。站会就是一个例子，现在已经变得非常普遍。然而，站会（在我看来）只是许多合作方式中的一种——所以不要仅仅因为某个过程要求就每天举行站会。如果你能找到更好的工作方式，那就去做吧。

• 你的“完成定义”是什么？ 这与设定期望有关——如果有一个共同的标准，你的团队就知道期望是什么，这有助于让每个人都保持一致。

质量保证

• 如何测试以及你的质量保证策略是什么？ 你需要决定是专注于手动测试还是自动化测试。如果你的应用程序庞大且复杂，功能繁多，那么一个以自动化为中心的策略是有意义的（这又回到了招聘/培训合适技能的问题上）。
• 你使用哪些工具？ 你使用的工具不仅支持你的团队，作为CTO，你还必须确保这些工具是合适的。这意味着它们需要符合适用于你的行业标准，并且在成本和效益之间找到合适的平衡。
• 你的应用程序中有多少个bug，这些bug是增加还是减少？ 你应该了解应用程序中的bug数量，以及这些bug是增加还是减少。如果bug数量在减少，这是好的。如果它们在增加，你将需要调查并找出原因。关键在于你需要找到并追踪正确的指标。

持续集成与持续部署

• 你将使用什么样的CI/CD流水线？ 确保所选的流水线与你的技能相匹配，并且适合你的组织。不要过于复杂，也不要被那些吸引人的新工具所分心。
• 你的代码分支策略是什么？ 确保你的分支策略符合你的需求，并且不会阻碍开发团队或造成不必要的痛苦（例如，长期存在的特性分支导致痛苦的合并）。
• 你多久部署一次？ 如果你希望频繁部署，你是否有相应的技术来支持这一点？如果没有，设定一个目标（例如“每月部署一次”），然后制定一个计划来实现这个目标。
• 你如何确保部署成功，如果不成功，你如何回滚？ 你不能假设一切都会顺利进行——你也必须为不顺利的情况做好准备。希望不是一种策略。

运营

• 监控工具将使用哪些工具，谁负责监控？ 如果你运行一个生产系统，你必须对其负责。如果系统宕机，可能会对客户产生实际影响，因此你需要能够快速检测问题并及时响应。
• 谁负责支持工作，如何满足SLA要求？如果监控工具检测到任何问题或客户联系你，谁来处理？ 这需要一个明确的流程——你不希望出现每个人都认为其他人会处理这种情况（因此实际上没有人处理），或者有多个人互相干扰的情况。

作为首席技术官，技术是你与高管团队中的同行区分开来的关键。因此，你的技术决策应该在商业背景下恰当且有意义。技术是一种手段，它存在于组织中是为了服务于某种商业目的。

照片由 Markus Spiske 在 Unsplash 提供

栈

• 你将使用哪些技术栈，为什么？ 作为CTO，你需要负责技术决策——包括你选择的技术栈。很容易被最新的工具和框架所吸引，但请确保你选择的是适合你组织的技术。前沿工具可能尚未在业界得到验证，也可能不会长久，因此如果你使用它们，请做出有意识的决策并理解其中的权衡。

• 你如何保持技术栈的更新？ 新版本的软件不断发布，你落后的时间越长，升级路径就越困难。请确保你有一个管理版本更新的策略。

架构

• 你将使用哪些架构风格或模式，为什么？ 再次强调，技术决策权在于你。架构决策是一项巨大的责任，因为一旦做出决策，之后再改变会非常困难。一个库可以通过一些努力被替换，但根本性的架构改变可能意味着几乎完全重写。架构风格有取舍，例如，微服务是可扩展的，但会引入复杂性。确保你明智地选择，并考虑上下文和取舍。如果你需要可扩展性，你会选择一种特定的风格。为了性能，你可能会选择另一种。Mark Richards 和 Neal Ford 有一个 非常好的指南 来帮助你做出这些决策。

基础设施

• 你将软件部署在哪里？ 你可以选择在本地部署或云部署。云部署相对容易实现可扩展性，并将原本需要的大量前期资本支出（“CapEx”）转化为运营支出（“OpEx”）。然而，如果你选择云部署，你需要考虑其影响——你的软件是否会在某些国家因监管限制而无法在云中运行（例如，某些非洲国家的金融服务系统）？此外，还要考虑“云原生”解决方案与特定供应商的专有工具（例如 AWS Lambda）之间的差异。前者可以在不同的云提供商之间轻松迁移，而后者虽然可以加速你的开发和交付过程，但迁移至其他云提供商则会变得更加困难。
• 你的灾难恢复（DR）策略是什么？ 事情可能会出错——系统宕机、数据丢失或损坏、有人在生产环境中运行没有 WHERE 子句的 SQL 查询。当这种情况发生时，作为 CTO，你需要确保你的组织能够应对。你需要定义你的恢复点目标（RPO——你将丢失多少数据）和恢复时间目标（RTO——恢复系统所需的时间）。你有多种选择，但每种选择都有其权衡——简单的备份/恢复 DR 策略相对便宜，但可能会丢失更多数据，而运行具有即时故障转移的主动/主动环境则成本更高。作为其中的一部分，确保你有一个运行 DR 测试的策略，并确保你有正确的数据可供备份。
• 你多久部署一次？ 如果你希望频繁部署，你是否有相应的技术来支持？如果没有，设定目标（例如“每月部署一次”），然后制定一个计划来实现这一目标。
• 你多快可以启动一个新的环境？ 使用基础设施即代码（IaC）可以让你相对快速地启动新的环境，而手动配置的服务器则很难复制或替换。这是 DevOps 中的 牛 vs. 宠物 概念。

技术债务

• 你有多少技术债务？ 技术债务指的是我们在短期内为了加快交付而做出的决策。这是另一个关键指标。技术债务并不一定是坏事——但它是一种权衡，你应该把它当作需要偿还的“债务”，在它给你带来麻烦之前还清。你可能为了交付一个MVP而承担一些技术债务——也许是一些在用户数量较少时不会被注意到的性能上的捷径。然而，你必须有意识地做出这些决策——记录下来并优先解决，以免在拥有100,000用户时系统变得性能不佳。

一些行业，如金融服务或医疗保健，比其他行业受到更严格的监管。作为 CTO，确保您的系统遵守规则是您的责任。

照片由 Giammarco Boscaro 在 Unsplash 提供

数据

• 你将存储哪些数据，这些数据将如何被访问？ 从架构的角度来看，这意味着要将操作数据存储和分析数据存储分开——如果你在事务系统上运行分析，你可能会面临性能下降的风险。从监管的角度来看，有一些法律你必须遵守——这包括南非的《个人信息保护法》(POPIA) 或其他国家的《通用数据保护条例》(GDPR)。如果你在这方面出错，你的组织可能会陷入麻烦。根据你的行业，可能还会有其他法规适用（例如医疗保健行业的《健康保险可移植性和责任法案》(HIPAA)，金融服务法规等）。

标准

• 你需要遵守哪些标准，你的流程是否符合这些标准？ 如果你与某些大型企业作为潜在客户合作，他们可能要求你遵守如ISO27001这样的标准。作为CTO，你需要确保你的流程符合这些标准，以便将来能够获得认证。

网络安全

• 你的应用程序是如何保护的？ 从应用程序设计的角度来看，确保系统中的数据得到适当的保护——有些数据可能是公开可访问的，而其他端点则需要用户进行身份验证和授权。这可能采取OAuth或其他机制的形式。需要注意的问题包括对象级授权漏洞和SQL注入漏洞。

• 你的基础设施是如何保护的？ 如果你在云中运行，请确保启用了多因素认证，应用了最小权限原则，并且有适当的日志记录和监控。如果攻击者获得了管理员门户的访问权限，他们可以造成破坏。你的云提供商也会提供工具来帮助你监控是否符合最佳实践（例如Azure Advisor或AWS Trusted Advisor）。

• 你的备份是如何保护的？ 仅仅有备份并不意味着足够——如果备份存储在与主数据存储相同的地方，并且攻击者获得了访问权限，他们可以破坏源数据和备份。

• 你的网络是如何保护的？ 这适用于你是在本地还是在云中，它不仅涉及保护数据——DDoS攻击可以使你的应用程序无法使用。

• 你是如何管理外部依赖的？ 现在，你的代码不是孤立存在的——它建立在由第三方生产的层层工具和框架之上。这很棒，因为它允许我们加快开发周期，因为我们不必重新发明轮子。但它并不总是好的，因为你并不总是知道代码库中有什么——一个带有关键漏洞的过时库或某人潜入看似有用的工具中的恶意代码。确保你有适当的工具来提醒你如果依赖项引入了风险。

作为高管，你扮演的是一个业务角色——这意味着你需要对财务和战略都有一定的理解。这与你之前在特定技术角色中的工作方式有很大的不同。

照片由 Luke Chesser 在 Unsplash 提供

财务

• 你的IT运营效率如何？ 作为CTO，你可能需要花时间与CFO交流。为了有效沟通并弥合他们的世界与你的世界之间的差距，你需要掌握一些财务术语，比如投资回报率（ROI）——你花的钱得到了什么？确保你对工具的投资是适当的，并且你的软件开发工作是针对正确的事情——花几周时间优化一个次要功能是时间和金钱的浪费。
• 你的基础设施支出是否优化了？ 如果你在云中运行（如果你使用云服务），你的云提供商可能会提供成本优化建议——确保审查这些建议并找出节省成本的机会。例如，如果你在Azure或AWS上使用虚拟机，预留实例可以让你在点击几次按钮后在一年内节省30%以上的费用。同时，考虑实际资源利用率，看看你的基础设施是否适当配置或过度配置。鉴于云的弹性，当需要时，相对容易地进行缩放。
• 你正在投资什么？ 如果你正在构建一个产品，如SaaS解决方案，那么该产品是公司的资产。因此，它可以在你的资产负债表上进行资本化。如果你为客户工作并为他们运行软件，那将是你的销售成本的一部分（COGS）。我不是CFO，所以不会深入讨论这些细节——但这一点强调的是你应该能够展示你的时间（以及你团队的时间）是如何分配的，因为这具有货币价值。我知道时间表可能会令人沮丧，但请超越流程，看看它能带来的价值。

策略

• 你的业务战略是什么样的，技术路线图是如何支持这一战略的？ 作为CTO，你可能不需要负责定义整个组织的战略。然而，你应该参与其中并发表意见。你的技术路线图应该与战略保持一致。如果战略重点是进入新市场，你如何确保你的应用程序可以在这些地区使用（回到监管机构和云友好性这一点）。如果战略是占领现有市场并使用户数量翻三倍，你如何确保系统的性能足够。

虽然这是一系列问题，但这并不是一个详尽的列表——你可以根据你的具体情况添加任何其他相关内容。

无论你是新晋升的CTO，还是已经在该职位上工作了一段时间，你的职责将非常广泛，涵盖各种关注点：人员、流程、技术、法规遵从性以及业务。为了成功担任CTO，你需要关注所有这些方面——具体需要多少关注，则需要根据你自己的独特情况来决定。

我希望，我还是帮助你提出了正确的问题，并且让你考虑了CTO角色的许多不同方面。

请在评论中分享您的想法——我还错过了哪些教训或问题？

在我写这篇文章的时候，想到了几本书。这些书值得CTO们阅读，以回答我在文章中讨论的一些问题。

《The Manager’s Path》 作者是 Camille Fournier

软件架构基础 作者 Neal Ford 和 Mark Richards

真诚批判 作者：Kim Scott

免责声明: 和往常一样，本文中的观点仅代表我个人。

也发布在 LinkedIn： https://www.linkedin.com/pulse/new-ctos-guide-world-responsibilities-riaan-nel-bdm7f/