导读：这将是一篇你在第一家科技初创公司任职CTO的完整指南。

现在，数百万开发人员、工程师和编码员在软件公司中发挥着重要作用，指导增长、构建结构和支持团队。这些开发人员担任首席技术官或首席运营官。 

承担运营方面的重大责任需要转变思维方式、技能和观点。对于任何开发人员来说，这都是一次成长之旅，你将按照自己的步调和方式进行成长。 

这篇文章是为了分享我作为开发人员指导新公司方向的一些个人经历。我将分享这次旅程中的一些重要观点，以及我在此过程中学到的一些东西。

什么是 CTO？ 

曾经，创业只是少数有特权的人才能做的事情。如果你有资本、想法和足够的投资者，你就可以创办一家初创公司，也许还可以经营一家成熟 企业。而到了今天，几乎任何人都可以创办企业，无论资源多少。

创业在科技行业尤其扁平，开发人员可以越来越多地为自己的想法的创造和实现做出贡献，只需要少数投入即可创建最小可行的产品。
  

据 GEM 全球报告显示，每年有超过 1 亿家企业成立。在美国，按行业追踪初创公司，其中超过 50,000 家注册为软件公司。在美国，软件业约占全球经济的 10%，而且还将继续增长。而且，即使像亚马逊和 Facebook 这样的服务导向型组织在技术上也是“软件”公司，软件已经构成了现代商业的大部分。  

这一巨大的转变，不仅导致了公司成立数量的变化，也导致了公司运营者变化。以前，公司需要精通商业的利益相关者来掌控并推动投资和融资。现在，软件开发人员通常与有想法的人合作，或者干脆自己工作。

但是，虽然愿景从小处开始，但很快就会实现，使产品成为一项业务。因此，正是那些投入工时编写项目的开发人员最终引导了业务增长。开发者变成为 CTO。  

这一旅程在许多小型企业中都有体现，包括我自己的 Nmbrs 企业。  

当我现在的合伙人 Michiel Chevalier 找到我时，我便开始了软件工程师的旅程。他的开发薪资/人力资源应用程序的概念非常有吸引力。我们有机会从头开始构建新产品，有机会设计架构，按照我们想要的方式编写代码，并构建我们真正相信的应用程序，这是不容许拒绝的。 

当我们开始创业时，团队只有 3 名开发人员，包括我自己。这项工作技术性很强，每个人都坐在同一张桌子上，一起吃午餐，协调彼此想法，并一起构建产品。没有人去考虑什么组织架构。 

我公司的第一阶段，大约有 6 个月的纯粹开发。当我们将系统上线并开始让客户加入平台时，一切开始发生了变化。 

需要什么样的结构  

一旦平台开始增长，你就需要组织结构。

客户需要每天在应用程序中工作。你必须围绕客户的需求来组织工作。  

这改变了我和团队的工作方式，因为我们不能在工作时间推送更新。我们还必须在部署之前开始进行适当的测试，以防止错误并保持产品质量。而且我们需要随产品更新推送技术信息和文档，以帮助解决用户问题。 

这个阶段的公司需要构建技术运营。必须有人负责确保我们能够交付和支持新产品，同时保持产品质量和价值。  

谁应该担当这个角色？最有可能的是，它会是一名开发人员，因为你需要了解应用程序和技术堆栈。

但是，你可能会被迫进行更改以支持客户、确保稳定性并围绕交付质量组织应用程序，而不是指派某人创建运营结构。  

作为我们团队中的高级技术人员，我最终承担了这个角色。我的职责从纯粹的技术转向处理操作。我慢慢地离开了编码角色，专注于构建技术操作，包括开发和测试环境以及基本的部署管道。 

我相信现阶段大多数组织都会保持同样的情况。创始人、联合创始人或高级开发人员将负责确保持续且可预测的质量。为什么？这样做意味着创建架构，以确保质量测试、实施部署管道以及创建舒适的工作环境。这需要对编码、技术堆栈和已开发的平台有深入的了解。  

对于一些开发人员来说，这也是一个相对容易的步骤，特别是对于那些习惯在现代环境中工作的人来说。

例如，像Netflix这样的团队已经要求程序员制作自己的工作管道。在这个阶段转向管理技术运营实际上只需要改变你的思维方式。就如同拉姆·查兰（Ram Charan）的“领导力管道”一样，进入下一步需要改变你的工作方法，从执行技术任务转向让其他人能够很好地执行这些任务，达到特定的质量标准，并产生可重复的结果。  

作为一名首席技术官，您更应该关心的是如何让团队能够完成高质量的工作，也就是结果。

• 开发战线  

• 一切都是产品  

• 部署管道  

• 质量控制  

• 流程和文档  

技术团队的结构构建  

人才是任何科技公司的命脉。在产品型公司中，运营围绕原材料、工作、生产、设计和产品测试等不同概念展开。

在软件公司中，人才是你的原材料和劳动力来源。一切的设计都是为了支持人员和组织结构，使他们能够从事大型项目。例如，研发与运维团队。  

组织团队是确保组织成长的首要任务，也是最关键的方面之一。

如若没有这个组织，任何事情都难以扩展。但初创公司很少有适合的组织，任务是临时委派的，责任是根据谁可以完成这些任务来委派的，而且通常几乎没有任何安全、文档或透明度。  

团队架构包括任务和责任委派、用户访问管理、优先级、质量控制和团队设置。

最后，你必须将产品分解为更小的模块，以便可以将这些模块分配给团队，并向团队提供该模块的完全所有权，以鼓励人们对产品的质量、自豪感和创新目标。  

随着组织的发展，它会吸引越来越多的人加入。这是增长的必要，但是也会带来了新的挑战。

特别是在技术型组织中，设计团队架构的人员必须完全了解产品。在这里，团队结构、团队规模和组织将真正决定或破坏组织交付产品、交付质量甚至职能的能力。这个角色几乎总是由接管设计操作的同一开发人员承担。  

我的 Nmbs 增长迅速。随着越来越多的人采用我们的产品，越来越多的客户改变了需求，并且需要增加和更好的技术支持。我们需要改进技术平台来支持客户及其需求。我们还想继续开发新功能，于是团队自然而然地成长了，然后我们的开发人员从 3 名增加到了 20 名。 

20人的团队似乎多了。作为产品负责人，我决定设计更小的团队。我承担了在产品中创建清晰模块的任务。然后，我设计了更小的团队，将每个人分配给这些特定的模块。 

设计团队在很大程度上取决于你的环境、公司的发展阶段以及产品的规模和复杂性等内部因素。  

一般开发人员——熟练的专家几乎可以改变任何组织的游戏规则。这就是为什么公司会争夺顶尖人才，并为已经成名的专家支付每小时数百美元的费用。但是，这些人很少适合小型组织。熟练的专家通常专注于一件事。如果他们想取得任何成就，就需要一个支持团队。

出于上面这个原因，我强烈建议专注于招聘通才，直到你拥有适当的公司架构和员工来支持用户体验专家等相关人员。  

跨职能团队——团队自然地围绕工作组形成，通常是某一类型的工作（例如销售、营销、IT）或基于产品。虽然前者在历史上很长一段时间都很流行，但我个人强烈推荐第二种。 

在 Nmbrs，我觉得保持原来的工作方法非常重要。团队应该对他们正在做的事情拥有完全的所有权。与跨职能团队的小模块合作使我们能够保持这一点，即使我们已经分成了更多小型团队。 

良好的科技初创团队结构包含跨职能任务，以便团队都可以拥有产品。跨职能团队不是通过将专业知识分组在一起来创建孤岛，而是将从事同一产品或模块的人员组合在一起。

设计团队，特别敏捷的团队设计要将来自不同背景、文化和工作环境的人们融合在一起，这是一件有意义的事情。

设计团队还表示要整合具有不同经验水平、能够以不同方式做出贡献的人们。围绕能够指导团队的高级人员或领导人员完成团队创建，让中级经验人员完成大部分工作，并确保团队中有初级人员或新人员最终接管，这始终是团队进化的好主意。  

关于团队规模——最后，团队规模对于敏捷性和产品质量至关重要。大型团队可以可靠地执行相同的工作，工作产出的波动很小，因为即使有人辞职、生病或因其他原因无法执行工作，也总是有足够的人员。大团队的开发速度也很慢，它们有更多的层次结构、更多分配的角色，以及在需要做某事时需要讨论的更多内容。

小的团队（例如 4-5 人）通常速度更快、更敏捷，并且能够更好地创新和快速行动。由于追逐新想法所需的管理很少，这些团队非常适合承担敏捷项目。

上面两种团队都有自己的位置，通常是在不同的方面。  

随着你的组织发展以及你拥有更多资源和更多客户需求，团队会自然而然地发展。随着你的成长，还必须考虑你希望这些团队如何协同工作。  

迈向敏捷 

更多人员的团队意味着更多的开销、更多的管理和更多的任务委派。在过去，只有一种选择。使用瀑布式业务实践创建层次结构和管理层。  

如今，大多数软件公司选择了不同的方法，比如敏捷开发方法。  

瀑布开发与敏捷开发的区别

Nmbrs 的团队约有 20 人，需要坚实的结构来组织我们的团队和成长。

我研究了我们的需求，并决定采用敏捷 Scrum 方法。此方法非常符合我们现有的理念，我相信我们可以在对软件开发方式影响最小的情况下实现它。我还聘请了一位敏捷教练来帮助实施，我也强烈推荐大多数软件公司采用敏捷方法。 

敏捷是围绕丰田方法构建的几种开发方法之一，丰田方法是丰田开发的一种早期工作管理方法。虽然每种方法都有自己的优点和缺点，但不会在这里详细讨论（更多信息请参阅敏捷方法的愿景到价值）。

我将与各位讨论为什么我推荐敏捷方法，以及为什么集成看板和 Scrum 等方法的重要性。  

为什么要使用敏捷？

敏捷是一种旨在帮助软件开发组织快速运营、降低成本和减少浪费的方法。

需要采用精益管理的许多原则来减少前期投资和规划，并将计划分解为可以快速完成的较小部分。

这个想法的目标，快速生成更大解决方案的小部分可以使组织更快地发现问题、更快地交付价值、并更快地响应变革的需求。

敏捷方法通常分为两个主要框架：Scrum 与看板方法。  

• 看板——看板是一个围绕持续开发和交付构建的框架。它使用视觉规划来帮助团队始终如一地处理小任务，以快速但结构松散的方式，从开始到完成。  

• Scrum – Scrum 将复杂的任务分解为故事，并在工作流程中可视化。工作是围绕冲刺进行的，团队致力于在设定的时间内执行一致的工作负载，从而实现可预测的长期交付。 

那么，你需要哪一个？我坚信任何软件公司两者都需要。你的团队结构必须包含满足这些团队需求的框架。事实上并非每个团队的所有工作都是相同的，具有可预测工作量以及对质量控制和可预测性有强烈需求的团队应该与 Scrum 合作（例如维护团队）。

具有更多临时工作的团队可能需要看板，因为他们会在 Scrum 环境中失败。   

敏捷开发  

早期组织很少需要强大复杂的部署管道。你最初创建技术结构的努力最多可能只是初级的。如果不显著编离实际开发，你的组织将没有时间或资源做更多事情。

最后，这种情况将会改变，工作债务将会增加。没有强大的管道的成本比花时间开发管道的成本还要高。  

什么时候会发生这种情况？这确实取决于任务。但最终，你将必须满足合规性法规，手动重复性任务将变得难以承受，质量管理将成为一项全职工作。改变团队与技术架构将提高质量、减少投资并让团队能够做得更多。  

部署管道与质量控制机制——大多数开发人员在自己的环境中工作，并且必须将工作推送到实时环境中。建立质量门控，审批、质量控制、审批等多个步骤。在此处，代码必须满足代码分析、性能、安全性和功能的标准，然后才能进入下一步。

这使得你可以根据修复时间尽早解决问题，从而大大降低以后解决这些问题的成本。  

QA 自动化– QA 自动化使开发人员能够更快地行动，将代码推入质量保证阶段，而无需等待 QA 来执行此操作。

虽然你仍需要手动 QA 审查，但 QA 自动化意味着开发人员可以将代码从自己的环境直接推送到 QA 测试环境中，然后可以简单地继续处理代码。  

一切都来自源代码控制——你的组织规模越大，回滚变更和问题就越困难。因此，创建一个支持从源代码控制引导的结构至关重要。在这里，所有工件（代码、数据库、配置、库、测试等）都在源代码控制中，允许你引导完整的应用程序，而无需从外部配置或数据库状态中提取。  

代码版本控制——应用程序大小在多种方面成为一个问题。更新包越大，它就会变得越复杂。理想情况下，开发人员可以创建代码并在完成后将其推送到实时应用程序。在大型应用程序中，这样做会破坏应用程序或导致严重的瓶颈，因为总是存在相互依赖关系。

较大的应用程序必须使用代码版本控制、红/黑/灰等环境、代码标记或每种技术的组合等技术来推送更新。

这样做意味着创建新结构和技术能力。  

流程管理——流程和文档是敏捷开发合规性最重要的方面之一。在这里，你必须制定适当的流程来指定质量和标准，必须记录变更及其原因，并且必须维护票证、事件和更新的日志。这些应该整合到日常工作和团队使用的工具中，以确保持续使用和相关性。  

组织团队、促进成长  

简单的团队设计能帮助你所在组织扩展到一定程度，再大一些就需要再调整了。

之后你将需要在团队之上增加一个组织层，让专家们能够相互沟通并防止出现孤岛，这是至关重要的事情。

太大的团队会互相妨碍，而小团队通常无法一起承担大型项目。跨职能团队仍然需要与各自领域的相关人员进行沟通。并且，确保所有团队之间的沟通非常重要。

如何在技术研发环境中应对这些差异？  

Spotify 方法是一种解决方案，也是我向大家强烈推荐的一种解决方案。这对于软件公司尤其重要，因为产品开发、客户支持和技术运营紧密地交织在一起。 

• 小队——小队是团队，拥有模块的端到端功能。小队是自启动、自组织和跨职能的（允许他们自治）。  

• 部落– 同一业务区域或模块内的小队集合。这使得小队可以处理对于一个小队来说可能太大的模块或业务领域，而不会失去沟通能力。  

• 分会– 基于工作领域（例如前端或后端应用程序、业务领域等）的跨团队人员的大型组织。这使得分会能够讨论想法、见解、方法并在团队之外进行合作。  

• 行会– 行会是基于共同利益（例如质量保证、设计、开发等）的跨团队结构。这使你可以看到在单个房间中拥有 IT 的好处，而不需实际创建这种孤岛。 

上面这种敏捷团队结构，可以有效减少整个组织中的孤岛，从而避免技术专家与各自领域的其他人隔离，同时创建能够进行跨朋友互动和协作的自治，包括创建跨职能团队。  

敏捷团队结构有助于减轻组织的管理负担，人们可以花更少的时间管理团队的日常工作，而将更多的时间用于创造价值。

敏捷团队进行自我管理，Spotify 模型等方法可以帮助我们在更大范围内实现这一目标。敏捷团队还应该扩大规模以实现增长，这些步骤将包括对新员工实施指导、员工发展、资源管理以及防止团队规模过大等措施。  

扩展到一个新水平 

随着团队和组织规模越大，你和组织将面临的挑战就越多。自动化、监控、授权和招聘策略等方面对于增长和组织安全至关重要。  

当我第一次担任 Nmbrs 首席技术官时，我参与了这些所有事情。我当时做出了与招聘、团队授权、质量控制方法等相关的决策。

当我们的员工人数超过 50 人时，我不可能可不再参与每一个小细节。我的角色变成了授权，确保有人对一些事情负全责，并且利益相关者和产品负责人自己修改和改进流程。

我不可能同时出现在所有地方，屏幕前的你也不能。相反你必须再次退后一步，学习如何将以前的职责委托给其他队友，以便他们能够表现和持续改进。

团队有机会监控和改进自己至关重要。这就需要集成相应的监控工具、框架来自动监控应用程序事件、基础设施资源、成本管理、支持等。它还意味着建立一个触发器和可操作反应系统，以便团队拥有响应触发器的工具集。  

质量监控——质量监控实施框架来衡量和管理团队、应用程序以及与应用程序相关的任何事物的质量和健康状况对于支持扩展亦至关重要。

组织需要自动化的质量管理、安全性和运行状况监控。我们不可能手动监控包含数百个模块的应用程序。你必须设置直接链接到工单、工单结果和责任方的触发器。当出现问题时，团队需要工具来自动识别问题，并提醒相关人员注意此问题。  

标准化流程——你的组织越大，从事相同工作的人就会越多。

在整个组织内拥有标准化的流程和工作方法非常重要。当标准化流程实施时，每个人都可以进行无缝协作、共享工作并融入彼此的工作。标准化流程支持文档记录、透明化，并随着产品和工作的变化，可以将工作移交给新加入或新创建的团队。  

与其他部门合作——软件和互联网公司使许多业务领域更加紧密地联系在一起。财务部门并不是自己的部门，因为发票功能已集成到工具中。

而现实中，销售和营销的工作经常重叠。当客户提出问题时，销售和营销需要知道开发团队正在做什么。客户支持需要了解销售对客户的承诺以及新产品功能的作用及其原因。开发人员需要了解客户想要什么、不喜欢什么以及原因，这些只有通过与销售和客户支持沟通才能获得。

发展可扩展的团队意味着将这种协作和沟通整合到你的团队结构中。  

结论

各位，不论你的组织处于初创阶段，还是正处于成长阶段，我们都会一直处于成长之旅。

本文中内容是有关我的旅程，当然每个人的旅程都将不尽相同。你可能会经历不同的事件顺序，学到不同的东西，并遇到不同的问题。

你的CTO经历有什么不一样吗？欢迎联系我们，分享你的故事。 

作者：

Luis Gomes de Abreu 是一位科技企业家、作家兼首席技术官。2008 年，他与其他人共同创立了薪资和人力资源软件公司 Nmbrs，并担任首席运营官和开发总监，负责技术运营。

编译：场长

来源：

https://www.visiontovalueframework.com/the-journey-from-developer-to-cto/