在为初创公司工作和指导初创公司时，我注意到 CTO，尤其是首次担任 CTO 的人（包括本人）每天都会犯一些非常常见的错误。

我认为该列表可以为那些有兴趣担任 CTO（或技术联合创始人）的人提供参考，或者正在为自己的初创公司寻找 CTO 但您没有技术背景审查新兵。

正文内容如下：

1.技能和资源错位

在工程组织中工作的工程师、设计师、PM 和其他角色有各种形式和规模，对于 CTO 来说，了解每种类型的个性和技能集的细微差别并相应地分配它们是很重要的。

2.专注于工程非杂事

工程师并非都是一样的。UI设计师、软件工程师、架构师、解决方案开发人员、DevOps运维 工程师、前端工程师等都专注于完全不同的工程角色和专业，并且技能和流程通常是不可转移的。

年轻的 CTO 常犯的一个错误是认为任何可以编写代码的人都可以计划、设计、架构或管理。例如，AI工程师/实习生通常在机器学习算法和数据管理技术方面拥有深厚的科学和特定领域的专业知识，但通常AI工程师不需要担心维护面向客户的故障转移和高可用性要求部署，因此他们不适合成为工程组织的架构师。

3.痴迷于构建却没有准备好调试

年轻的 CTO 通常是工程师出生背景，这类人他们习惯于构建并且引以为豪。典型工程师的心态是您不仅为你构建出的功能感到自豪，还为代码的质量感到自豪，因建构而得的自我满足而自得其乐，也因此忽略了为创建好的代码输入一个编写自动化单元/集成测试的需要。

事实上，当CTO被问及要求时，许多工程师出生背景的CTO的反应是倾向于采取防御措施，并认为这种做法是浪费时间。

4.全程跟踪监控

建议设置全跟踪监控，跟踪从网络连接、前端渲染、服务器端执行到数据存储的所有内容。（XXX 和 YYY 是不错的入门选择）您将需要它来在瓶颈发生之前识别它们，并在系统出现故障时快速识别问题。其次，为系统的关键部分编写至少一些单元测试和集成测试，它将为您节省无数时间来诊断系统和查找故障所在。

5.不负责任

不幸的是，这比我们想象的要普遍。大多数被视为行事风格不负责任的 CTO 他本身并没有恶意如此，只是在心理上准备不足，一时之间无法应对作为工程组织中领导者身份的压力。

主要区别在于思维方式：工程师只负责他或她的代码，而 作为一个已经具备领导者身份的CTO 他需要从一个固有思维(工程师)中进入到管理层的思维，即负责生成的所有内容以及生成代码的所有流程。

如上述所指出的未意识到自己身份上已经改变的CTO，他可能会被视为一个不负责任的 CTO，造成这类冲突的关键是通常停留在工程师的思维模式中，他会拒绝对其他团队成员负责，尤其是对下属。

建议是，当事情出现问题时，CTO 需要被提醒需要带头诊断问题，并且向公司的其他职能部门解释问题来源，并向公司提出可行的计划以尽快解决/解决问题。

在面临紧急情况发生的危机时期，CTO 最不应该做的就是将错误归咎于某一位特定的工程师，或是说让某一位工程师来背负所有成败的罪名，并且不对 CTO 监督下的问题承担任何责任。

6.对纵向和横向任务分配的误解

同样，当你是一名工程师时，你不会考虑这些事情。您考虑敲击键盘，从头到尾编写代码，然后注销并回家。

但是当你成为一名CTO负责一个工程团队时，你需要知道如何分配工作并正确地完成工作，这将我们带到了垂直和水平任务分配的话题上，这是很多初创 CTO 倾向于吮吸的话题。

如果您将工程产品视为堆栈，并且该堆栈需要提供给不同的渠道和客户。这里的任务垂直分布是指通过分离堆栈的不同部分来划分工作，而水平分布是指我们通过分离不同渠道和/或客户的可交付成果来分配工作。

7.为什么这是个问题？

因为对于早期的创业公司，人们往往身兼数职，做横向任务分配，让一个工程师“做 web 应用程序”，另一个工程师“做 iOS 应用程序”是很常见的。

这很糟糕吗？不一定，这会训练人们学习可交付成果的不同部分并变得更加通才，以便他们可以快速切换到不同的项目。

有什么缺点？当你这样做时，你是在牺牲技能的深度来换取广度。回到前面关于技能和资源错位的讨论，当一家初创公司扩张时，CTO 很容易陷入“为了可交付成果而竭尽全力”的心态，并误解如何利用经验丰富的工程专业知识。

因此？工程产出的雇佣人数回报将递减，因为没有正确使用更有经验的员工。

8.自我与屈尊

自我与屈尊，这听起来一点也不陌生，是吗？

startup初创/创业公司世界是自私人格的游乐场，有好有坏。

你需要有一个自我来抵挡反对者，但作为 CTO，你需要了解一件事：

你不可能在所有事情上都做到最好，你的工作是找到一流的人才并将组织凝聚在一起。

话虽如此，首席技术官的工作是学习和应对变化，而不是讲课和教书。

初创 CTO 的一个常见问题是无法交出任务并信任人们来完成工作。初创公司的 CTO（尤其是技术联合创始人）倾向于认为他们的方法是最好的方法，最终对反对意见和新想法做出冷酷的回应。

更重要的是，由于大多数工程师都属于一类或另一类，CTO 最终有可能会遇到无法理解其他类型工程师工作方式的情况。例如，如果 CTO 具有严格的 B2C 应用程序开发背景，那么他或她将很难理解什么是解决方案架构，因为 CTO 从来不需要为客户设计解决方案。

这些是许多早期创业公司（在 A 系列之前）遇到的一些最常见的技术管理陷阱，并且通常无法解决。这是我的两分愚建，希望它对那些希望成长为这个角色的人有所帮助。

编译：手扶拖拉斯基