创业公司CTO手册（二） —— 人员与文化

管理基础

推荐阅读：《管理人类》(Managing Humans) —— 麦克·洛普(Michael Lopp)

管理的黄金法则：尽一切可能使你的团队发挥最佳状态。在技术领导和其他领导角色中一样，作为经理，你的绩效最好的评判标准就是团队本身的绩效。这意味着你应该思考并花时间做一切必要的事情来帮助团队成员达到最佳工作状态，无论是个人工作还是集体工作。

帮助你的团队取得成功需要谦逊，因为这意味着你要始终把下属的需求放在自己之上。你需要调整和调整自己的风格、行为、思维和行动，以适应你工程团队成员的需求。这包括愿意承认错误、思想开明，并从你的下属那里学习。

如果你相信这个过程，那么要知道你会犯错误。与团队一起承认这些错误，他们会更加信任你。也要知道，成为一个完美的经理并不是一个可实现的目标；你所能期望的最好的结果就是不断小幅度地提高。经过一生管理人员的经验，你会了解关于技术和人的方面的许多经验，这将使你成为一个更能胜任的经理。

在《管理人类：一个软件工程经理的直白和幽默故事》一书中，迈克尔·洛普写道：

与你共事的每个人都有一套完全不同的需求。满足这些需求是让他们满意和有效的一个方法。你的工作是全职地倾听这些人，并在心理上记录他们的构建方式。这是你最重要的工作。我知道高级副总裁会告诉你，对项目来说最重要的是按时完成，但你不会编写代码，测试产品或文档功能。团队将会做这些事情，你的工作是管理团队。

在这一个简明扼要的段落中，洛普点出了管理的所有关键点。首先，你是一个倾听者，一个个人发展和职业规划教练，一个能够抵御世界上可能分散注意力、造成压力或在其他方面阻止你的团队发挥最佳状态的外界力量的屏障。

职业技能树

许多视频游戏涉及到技能树的概念。对于那些不熟悉的人来说，技能树是一个在玩家进度中解锁的技能或能力序列。每个技能都可以通过花费技能点来解锁。在某个特定的时刻，有更多的技能待解锁，而你拥有的技能点不足以花费。技能树迫使你在其他之前选择一些技能。技能树同样也适用于你的职业发展。在任何一份工作中，你可能在积累某些技能点，而忽略了其他技能。

在你成为技术领导者的旅程中，你已经在技术/工程分支的技能树上投入了许多技能点。我对你的关键见解是，管理分支的技能树同样广泛，如果你到现在为止还没有在该领域投入技能点，即使你是一名100级工程师，你在新的领导职位上也将作为一名1级经理面对一棵巨大的尚未解锁的关键技能的橡树。一旦你的公司拥有了不止几个工程师，这些技能将在你能够与团队一起扩展的能力方面起到关键作用。

改善: 不断改进

“改善”是日本的一个词，它的意思是改进。这个短语是丰田生产系统的一部分而被广泛使用。在丰田，所有员工都会得到一个（真实或隐喻）红色的手柄，可以拉动，停止整个生产线。如果一个工人发现生产中的问题，这个想法是让他们拉动红手柄，组织同事和资源来诊断问题，然后在工作继续之前解决它。通过赋予团队中的每个人改善流程并投入到它的可行性中，丰田可以以更低的成本构建更高质量的汽车。

我不是第一个认为软件工程与传统制造业有很多相似之处的人（参见 Gene Kim 的《凤凰项目》）在这种情况下，让这个比喻变得真实：为你的团队提供一个数字化的红手柄，并鼓励他们关注不断改进你做的一切。优秀团队的成员明白，随着时间的推移，团队会改变，客户需求会改变，工具会改变，团队需要重新审视过去的决策并作出改进。

“改善”不仅适用于团队的流程，也适用于个人。你最优秀的团队成员将拥抱不断学习和不断完善的理念，并把错误看作是改进的机会，而不是失败。

教练

作为经理，你的主要角色是发挥团队成员的最佳能力，因此在许多情况下，把你的角色描述为教练而不是经理更为合适。教练是站在你这边的人，是团队中每个人的智慧和指导来源。一个教练会迅速提供关键反馈，也会是第一个庆祝和称赞成功的人。

在与直接下属的互动中，无论他们是个人贡献工程师还是经理，你的目标是成为他们曾经拥有过的最好的教练。

找到管理导师

为了加快你的领导过渡、指导和管理他人的步伐，建议寻找一位管理导师，而不是通过反复试错来学习。市面上有很多管理教练，他们的方法各不相同；挑战在于找到一个与你共鸣的人。

在我在WiFast（当时是Zenreach，现在是Adentro）担任业务领导者的第一份工作中，我们迅速雇佣了一支由10名全职员工组成的团队，其中大部分是工程师。作为一个第一次的经理，我知道我还有很多东西需要学习，我渴望利用一切资源去成为一个更好的经理。我的唯一问题是，我讨厌大多数管理建议。我发现它要么过于教条（先做X，然后做Y，然后做Z），没有上下文或深度洞察，要么完全没有实质性的内容（就像一堆废话）。直到我遇到我的第一个管理导师乔纳森之前，我都这么认为。

故事是这样的，我们的投资者之一First Round Capital在旧金山举办了一次管理高峰会议，距离我们办公室大约30分钟车程。到目前为止，我发现First Round的人都是高素质的，所以当我看到邀请时，他们的支持暂时缓解了我一直存在的废话过敏症，于是我报名参加了会议。

当我开车去参加高峰会议时，我发现观众相对较少，只有大约30人，足够容纳一间高中教室的人数。我坐在高中折叠桌面前，打开笔记本，拿出一支笔，在纸的顶部写下了日期和First Round Capital管理高峰会议。可惜，那是我在接下来的四个小时里写下的唯一一件事。

上午的前半段有三四位演讲嘉宾讲述了各种各样的主题，每个主题都没有提供可行的建议或深入的洞察力。午餐休息时，我正在考虑提前回去，在办公室度过半天工作时间。我查看了议程，并注意到下午的演讲者完全不同，所以我决定至少听完第一个演讲者。

午餐后的第一个演讲者是乔纳森。与之前的演讲者不同的是，他没有幻灯片，走到教室前时，他似乎有点匆忙，也许有点没有准备好，或者只是紧张。然而，他口中的第一句话却讲述了一个不同的故事：

让我透明地操纵你。

我永远都不会忘记那一刻。这是一个多么有趣的事情要说；这是一个矛盾的词汇，就像说这句话是假的一样。（如果你好奇的话，这被称为说谎者悖论。）他接着解释说，那正是他想要的：他想说一些话来吸引我们的注意力，他成功地做到了这一点。接下来的三十分钟里，我详细记录了笔记，不是关于操纵人的笔记，而是关于理解人类的笔记。

每一句乔纳森说的话我都铭记在心。当半小时的会议结束时，乔纳森说他要赶飞机，有些匆忙地跑出了房间。我低头看着笔记本，意识到在过去的三十分钟里，我已经写下了三页的笔记，然后站起身从椅子上跑出去追他。

我设法在他上黄色出租车时赶上他。有些恼火的乔纳森问我想要什么。我问他是否提供私人辅导。他回答说，让峰会的组织者联系我们。聪明地说，他没有在当场承诺提供辅导，而是留下给自己在决定是否值得花时间在First Round上对我进行尽职调查的机会。幸运的是，当我请求First Round提供联系方式时，联系人对我说的话不错，乔纳森同意了一次介绍性辅导会议。

一对一会议

一对一会议是你和直接下属之间的私下会议。很容易将一对一会议视为状态检查会议，并且议程完全侧重于与业务或技术主题紧密相关的事项。如果议程包括这些主题，也是可以的，但这是你建立与直接下属的教练关系的机会。你应该利用这个时间真正了解和理解你的下属的思维方式，挖掘和发现他们的优点，并识别出可以帮助他们最好的工作的弱点。

跨级会议

定期（每月或每季度）与向你报告的经理的下属进行会议是一个好的做法。由于你直接与他们会面，所以这些会议被称为跨级会议。你并不是试图削弱你的经理和跨级之间的关系，事实上，恰恰相反。通过收集更多的数据和听取不同的观点，你将能够更好地与经理合作，改善业务。

跨级会议的一些建议议程：

确保员工知道会议的目的，即你不是来解决问题或做出决策的人，这些问题应该由他们真正的经理处理。
让他们知道你想建立关系，并听取他们对领导力、文化、战略和公司方向的见解。
同员工建立联系；提问并产生好奇心。
网络上有很多好的实际模板/议程来处理跨级会议。我推荐您参考managementcenter.org提供的一个：ctohb.com/skip。

培训经理

随着组织的发展，你很可能会到达这样一个程度，即你不再拥有任何个人贡献者的直接报告对象。每个直接贡献者实际上编写代码的人都由一个中层管理人员管理。很显然，有效的中层管理者对你的组织绩效至关重要。你的工作是确保你的经理们有所需的支持、资源、培训和辅导，使他们能够最好地指导他们团队中的工程师。

最大的培养高素质中层管理人员的因素当然是雇佣合适的人，其次是持续的培训和支持。如果你有职责监督一组经理，我鼓励你在你的组织中建立以下内容：

构建一个持续学习的文化。
- 例如，鼓励你的经理们建立一个内部以管理为重点的读书俱乐部。
- 定期与管理团队共享你自己的见解，并要求他们与他们的团队做同样的事情。如果你正在使用一种公司聊天工具，那么为此类对话设置一个专门的渠道，比如#管理见解，这是一个很好的地方。
建立一个对培训和管理的高标准。
- 向你的经理们清楚说明你对管理的期望，对培训、一对一会议、绩效管理等方面的期望。
- 将你的管理期望明确地写入内部文件，并将其作为管理招聘和入职的一部分。
提供全面和易于获取的管理培训资料。
- 为你的经理们提供资源，使他们能够进行持续学习和专业发展。这可能包括公司订阅学习计划、赞助员工参加会议、雇佣管理教练或正式化内部或外部辅导计划。在你团队的常规预算过程中考虑这些培训资料的费用。
开展面向外部的思想领导文化。
- 鼓励你的经理们成为你们行业的思想领袖。这可以以公司的形式参与，例如作为技术或管理类播客的嘉宾，或在会议上发表演讲。

一对一工程师会议

你的工程师应该经常向你倾诉，所以如果他们这样做了，不要惊慌，这是完全正常的，事实上非常可取。你应该每隔两周或每周至少与团队的每个成员举行一次一对一会议。在这些会议中，你的目标是为你的工程师创造一个安全空间，让他们告诉你他们在想什么，并积极倾听和参与这些话题。

对于优秀的工程师来说，这意味着他们意识到周围世界的不完善之处，并希望告诉你。你的工作不是解决他们提出的每个问题；你的工作是倾听，通过提问澄清你的理解，并说服他们你确实理解，并引导他们找到解决方案。偶尔可能会有直接的要求或直接需要你帮助的事情，但这并不是常态。

你在这里提供的价值是让你的直接报告感到被听到，并指导他们有效解决问题。

一对一会议的内容和议程

最终，在一对一会议中，你的目标是与另一个人建立关系，并进行敢于承认和批评的关键对话，以帮助他们做出最好的工作。如果你的直接报告有一个广泛的议程，那很好，从那里开始。然而，如果他们的议程一直限于战术性的正在进行中的工作，而你没有讨论到更高层次的如何工作的对话，那我鼓励你补充他们的议程，这样他们就能更好地理解你会议的目的，并在今后的会议中提出更多实质性的问题。

沟通桥梁与他们的议程建立联系的最简单方法是建立一个共享文件，可能有一些结构/模板，以引出你认为重要的讨论主题。在会议之前提供这个文件，也为你和你的员工提供了一个共享的地方，在会议之间记录想法，在会议之前构思思路，所有这些都有助于使会议时间更加高效和有效。

还有几个能够促进一对一对话的SaaS工具。著名的例子包括Culture Amp和15Five。不过你不一定需要一个工具；一个简单的文件同样有效。我使用的模板可在ctohb.com/templates上找到；它包括了在个人、部门和公司层面上讨论喜欢的/希望的项目以及经理和员工之间的双向反馈。

一对一的剧本

建立一个这些工程一对一的剧本是确保这些会议涉及一组一致的议题，并且不偏离轨道的另一个有用的方式。你的剧本应该确保你的一对一会议涉及以下问题：

冲突：团队内部、工程团队之间、跨职能

绩效和发展：通常，你的工程师正在寻求关于如何改进某个问题的建议。

清晰度：工程师可能对某些问题有一般性的思考，并寻求你的观点，或者看看你是否有比他们更好的关于某些事情的信息。

背景：公司整体的情况如何，一个贡献者的工作如何与那些目标/目标相关联。

激进的坦诚

“激进的坦诚”这个词出现在Kim Scott的书《激进的坦诚》中。这本书将激进的坦诚定义为同时包含表扬和批评，并确保在传递过程中既有个人关心又有直接挑战。我认为这一点最好通过与《激进的坦诚》一书中列举的三种其他沟通方式相对比来说明：

讨人厌的攻击：有时被称为残酷的诚实或正面刺伤，以直接挑战为特点，但缺乏个人关心，可能通过虚伪的赞美或刻薄的批评来表现出来。

毁灭性的同情心：从个人关心的角度来看，沟通缺乏直接的挑战。

操纵性虚伪：也被称为背后捅刀或被动攻击的行为，既不表现出个人关心，也不直接挑战。

我鼓励你阅读Scott的书，但如果你不阅读，至少要了解这些术语，并将它们用作推动你的团队经常实践激进坦诚交流的辅导工具。

过度沟通的好处

对于员工来说，没有比感觉自己的经理与他们沟通不足更糟糕的了。在缺乏信息的情况下，假设最糟糕的情况是一种自然的本能；缺乏信息也可能是焦虑和困惑的主要原因。

相比之下，过度沟通几乎没有什么后果。最糟糕的是，过度沟通可能会分散注意力或变得多余，但这些问题可以通过深思熟虑地考虑过度沟通的形式来解决。因此，毫不奇怪，大多数初创公司都在努力将过度沟通融入他们的文化中，通常包括将此短语作为公司的核心价值观之一。

电子邮件

现在几乎与任何人的互动都要么是使用电子邮件已经有25年了，要么是他们从小学就开始使用，所以当然，这意味着他们知道如何有效地使用它，对吗？不幸的是，有效地利用工作中的电子邮件不一定是常识。因此，你需要帮助鼓励最佳实践。以下是有效使用电子邮件的一些建议：

不要让电子邮件成为你的工作。
- 与其整天打开电子邮件或不断监视它，不如每天固定时间检查电子邮件。
- 在你的手机上禁用电子邮件通知。尽管这个建议可能听起来亵渎，但我建议你尝试一下。这不仅可以显著减少你收到的通知数量，还会发现自己在你准备参与时会主动检查电子邮件。这使得电子邮件成为一种有意识的活动，而不是持续的背景麻烦。
每天达到零邮件。
- 在学习你的电子邮件工具或使用可选的电子邮件助手附加程序/插件来帮助分类和分拣电子邮件的过程中投入时间，以便在每天结束时，每天都有零封未读邮件。
- 清空你的收件箱并不意味着对每封邮件都采取行动或回复。如果你把电子邮件当作待办事项列表来使用，那也没问题（尽管这并不是理想的，请参见《会议和时间管理》的更好的待办事项替代品），只是确保将你的电子邮件待办事项从核心收件箱中分开，以免将其与未经分拣的电子邮件混淆。
不要在电子邮件中解决问题。
- 电子邮件是进行深入讨论的次优工具，尤其是涉及超过两个人的情况下。群组邮件最好用于协调和过度沟通，而不是解决问题。
- 要了解电子邮件往往缺乏细微差别和语气，这使得意图很容易被误解。
- 对于涉及复杂的群组电子邮件，你很容易写或参与，这是一个很好的指示你是时候选择同步对话以更好地处理所讨论的主题。一个15分钟的讨论通常可以解决一个20条消息的电子邮件线程只是触及表面的问题。
- 写下自己的想法往往是一种非常有成效的练习，但电子邮件并不是促进和记录这种书面头脑风暴过程的好方式。鼓励你的团队使用wiki来进行深思熟虑。
不要依赖电子邮件进行长时间或深层次的交流。
- 总的来说，电子邮件是一个不太适合长篇内容的媒介。长篇备忘录最好放在内部wiki或文档中，以便进行评论、更新，并且易于在将来引用。
保持邮件相对简短，最好使用重点的项目进行标点。
- 毫不犹豫地使用基本的格式，如加粗或高亮显示请求/行动项目。
考虑到你的受众。
- 工程师们通常更喜欢编写代码而不是阅读/回答电子邮件。问问自己，发送电子邮件是否真的是与你的受众进行沟通的正确方式。通常情况下，最好的沟通方法是他们偏好的方法，而不是你的方法。
- 很容易将同事从电子邮件线程中留下，不管是故意为了不洪水舱室，还是无意间的错误。如果你坐在那里考虑哪些人应该添加到/从电子邮件线程中删除，那说明邮件不是正确的交流方式。

同步聊天

你的公司很可能已经采用了某种同步聊天平台；在2000年代初，它通常是谷歌聊天或微软MSN的产品，而在2020年代，更常用的是Slack、微软Teams或Meta的Workspace。如果你目前不在这些平台之一上，考虑采用它们是值得的。

绝大多数公司，从初创公司到拥有10万名员工的巨头公司，都取得了这些平台的巨大成功。

实现这一成功意味着要注意并计划一些固有的缺点：同步聊天程序需要双方停下正在做的事情并参与其中，结果是对话组织不良，并且不会产生对团队有用的持久性产物。你可以并且应该认识到这些缺点，并通过为你的团队设定一些基本礼仪和期望来补偿它们在使用这些工具时。

Slack自己的博客在ctohb.com/slack中包含了一些常见的最佳实践。

以下是一些建议，有助于与同步聊天工具一起使用：

尽量在消息中包含所有必要的信息以继续对话。如果你问一个同事一个问题，提供足够的上下文和信息在问题中，给他们一个最佳机会全面回答。这样做可以减少发送通知的数量，减少来回沟通的次数，并缩短解决时间。像loom.com这样的工具非常有帮助。
使用消息格式化功能，如项目符号和标题，使更长的消息更易于扫描，相关信息更易于查找。
将对话集中在特定的频道或线程中。尝试同时跟进多个人的、关于多个主题的对话是低效且令人沮丧的。
尝试同时使用通知计划和勿扰功能。你还应该鼓励你的团队成员在任何同步聊天程序中设置勿扰计划，以尽量减少干扰。
在过度沟通的精神下，默认的交流方式是公共频道。更好的是，建立一种公共文化和标准作业程序，将对话和最终的决策转化为与终生，有组织的公司wiki或其他适当的文档/信息存储方式。
对于向多个人发送通知的消息，例如在Slack中的@here或@channel，要非常谨慎。尤其是在公司规模扩大的情况下，发送此类消息可能会发送通知，并打断数十名员工。

异步沟通

异步沟通是指不打算立即获得回复的任何沟通。为了有效，接收方应该能够花时间，处理信息，然后慎重回复。异步沟通的一个关键要素是初始消息是一个完整的想法，并包含必要的上下文，以允许对方作出回应。

一个陈腐的例子是令人畏惧的“功能损坏”的bug报告。几乎在所有情况下，bug报告应该进入一个故障记录系统，而不是直接发送信息。一个工程师收到一个消息中的bug报告，没有上下文，不知道哪个功能被破坏，以及以何种方式它未能满足期望。因此，工程师的回复很可能包含一些问题，需要与报告人进行更多的往返，浪费时间并引起沮丧。

相比之下，一个bug报告包括完整的书面重现步骤，以及一个用户试图使用该功能并展示故障的视频。很可能，这种方法将使工程师能够在不需要进一步跟进的情况下完成修复。

最重要的是：无论何时以异步格式向某人发送消息，都要给予对方他们所需要的所有信息，以便他们能够理解、处理并以推进对话的方式回复。

异步文化

非常令人惊讶的是，经过深思熟虑的异步沟通经常可以替代同步聊天或会议。良好的异步沟通不仅可以减少会议和打扰，还可以留下全面的书面文档，供他人在将来使用。一些初创公司，如Levels Health，实际上已经将异步作为公司文化的核心建立起来，取得了很大的效果（ctohb.com/async）。

文档

文档编写是扩大你的组织的一个关键要素。写下事情有很多好处：书面文档可以帮助新员工入职，培训，过度沟通，思考，全面性，建立文化，避免不必要的错误等。你的角色不仅仅是相信文档的价值和回报，还要建立一个重视文档的文化和一个重视文档的团队。

打造良好文档文化的一些建议：

以身作则，为团队树立榜样。曾经我带领团队从每周零篇内部维基文章转变为每天写数篇，大约用了八周的时间。我唯一做的鼓励文化转变的事情就是开始亲自写文章。我将自己认为对团队有意义的事情写成文章，并在合适的时候分享这些文章的链接。很快，其他经理也开始效仿，两个月后团队的每个人每周都有贡献。
将文档编写和阅读作为流程的一部分。无论是用于入职，技术规范，代码审查，内部意见征询（RFCs）还是备忘录，标准程序应该是将其写下来并在易于访问的位置保存为组织良好的文档存档。
建立适当的流程来维护文档。文档很容易变得过时，在许多情况下这是完全可以接受的。然而在其他情况下，保持文档更新是很重要的，唯一的办法就是有一个包括更新文档的流程或清单。在每个文档上都标明上次更新的日期是向读者发出信号，提示文档是最新的或可能已经过时。
鼓励团队遵循童子军规则（离开营地时比到达时留得更干净/代码改得更好）。如果他们发现不准确的文档，他们应该自己更新或明确将文档标记为弃用。

值得特别关注的一个文档领域是开发人员在特定项目或代码库中开始编写代码的方式。我建议每个代码库都有一个 README.md 文件，解释至少四个内容：

安装：如何在本地安装和运行应用程序
目录结构：如何在这个代码库中找到所需的文件
开发：在这个代码库中开发/运行/测试的循环是怎样的
部署：如何将更改部署到此应用程序的更高环境中

关于工作中的首字母缩略词

每个组织都有自己独特的文化，以及内部和外部沟通的风格。领导者的一个重要责任是确保文化始终支持组织的目标，而不是阻碍它们。

技术组织内部文化中容易失控的一个元素是杜撰首字母缩略词，随着时间推移可能会越来越多，使本应简化沟通的首字母缩略词变得更加复杂和模糊。这可能只是一个小问题，但它表明了问题沟通策略的不足，可能会失控，尤其是它可能会在懂行的人和不懂行的团队成员之间造成障碍。作为组织的技术领导者，您的工作是树立基调，定义组织文化，尽管杜撰首字母缩略词的普及很可能不会从您的身边开始，但在事情失控之前，您的工作是在问题出现之前识别并制止它。

2018年1月，埃隆·马斯克在一封面向SpaceX员工的备忘录中呼吁制定“无首字母缩略词政策”。从那时起，我一直执行同样的政策，并全力支持它。以下内容来自一封标题为《首字母缩略词真的很烦人》的电子邮件（ctohb.com/acronyms）：

SpaceX内部越来越倾向于使用杜撰的首字母缩略词。使用过多的杜撰首字母缩略词对沟通构成了重大障碍，而随着公司的发展，保持沟通的效果变得非常重要。虽然一个或两个杜撰的首字母缩略词看起来可能无所谓，但如果有数以千计的人都在捏造首字母缩略词，随着时间的推移，我们将需要向新员工发布一本庞大的缩写词汇表。这对新员工来说特别困难。评估一个首字母缩略词的关键测试是询问它是否有助于或妨碍了沟通。大多数工程师（包括SpaceX外的工程师）已经熟悉的首字母缩略词（如图形用户界面）是可以使用的。但实际上，大多数首字母缩略词会成为障碍，对于新员工来说很难理解。一个团队要维护一个首字母缩略词定义列表是需要付出努力的，而且总体上，首字母缩略词的写作和发言都没有看起来那么省时。

这可能看起来是亵渎的，或者是一个过分的和愚蠢的规则来试图在组织中实施。我不建议惩罚使用首字母缩略词的人，或者在公司的走廊墙上写下这个规则。相反，特别是在一个较小的组织中，只要轻轻一碰就可以使不使用新首字母缩略词成为文化的一部分。获得高管团队的支持，不使用新首字母缩略词，并鼓励他们向下层经理发出温和的提醒，要求做同样的事情，你会惊讶于每个人多快就能养成这个习惯。一两句在入职文档中的提醒通常足以提醒新员工，由于在入职中温和的提示和周围缺乏首字母缩略词的实例，他们将很少自己创建这些缩略词。

会议和时间管理

广义上讲，有三种类型的会议：定期的信息交流会议，冲突解决会议和自发/即席会议。作为经理，您的任务是根据会议的类型来设定出席者的期望。对于信息交流会议，请问自己是否开会真的是传达信息的最佳方式，有时是，但并不总是。如果是，确保以多种方式传达信息，也许提前在公司的维基中提供书面材料。如果是冲突解决会议，请务必事先确定讨论要点，以便与会者可以准备好讨论和解决问题。自发会议往往在起初就有明确的目的，不需要进一步介绍。

无论会议的类型如何，您安排的任何会议都应该有事先对被邀请者知情的明确目标。理想情况下，每个人在会议之前都应该有足够的信息，以确定对他们来说参加会议是否有价值。同样重要的是，您的文化应该赋予人们权力，让他们有权利决定是否参加会议，如果他们认为这不是一个很好利用时间的会议。

时间管理

作为一家创业公司的领导者，您很快会发现自己的时间被分配在许多种工作和每周可能持续几十个小时的会议中。如果您还没有一个适合自己的有效系统，那么现在是投资好习惯和组织的时候了。我建议从斯蒂芬·柯维的《高效能人士的七个习惯》和大卫·艾伦的《完成任务的艺术》开始这个旅程。

会议时间

您可以通过创建或允许大幅度的自由时间块来使团队提高效率。切换上下文（从一个无关的任务转到另一个）是很消耗时间的（参见ctohb.com/myth中的多任务迷思），因此您为工程师创造尽量长的时间块使他们能够不间断地进行工程工作，而不是切换到其他任务（如电子邮件、电话、会议），您就能减少总体的切换代价。

我赞成为团队设定一个非正式的会议时间窗口。鼓励工程团队和跨功能团队在每天的两三个小时窗口中安排会议，并尽量不在这个窗口之外安排工程师的会议。这样每天都会有大量的时间，工程团队可以专注于核心工作，并且为必要的信息交流和冲突解决会议留出空间。如果您的团队每天有三个小时以上的会议时间（每周15个小时，接近一半的工作时间！），您应该仔细审视这些会议，问问自己是否可以合并和减少会议次数。

其他团队通过设立无会议日取得了成功，每周一天或多天都没有安排任何定期会议。请记住，在每周40个小时的工作时间中，您的目标是尽可能多地为工程团队保留作为连续集中时段的时间。一天没有会议意味着8个小时的专注时间，但还有32个小时需要考虑，因此它不能解决所有问题。

工程师的时间推荐

考虑以下软件工程师的假设时间：

1小时：与经理的一对一面谈
2.5小时：每天每个小组的30分钟站立会议
2小时：平均停留在其他敏捷仪式上的时间（如冲刺计划、回顾等）
4到8小时：审查他人的代码
4小时：电子邮件/聊天沟通

总共，这就是一周大约13到17小时用于会议和沟通。如果再加上为切换上下文和意外打断所花费的时间，很快你会发现在一个40小时的工作周里，对实际集中时间而言大约只有一半的时间可用。如果您不注意会议安排的时间，那么您的工程师不仅仅只剩下20个小时来做核心任务，而且这些时间不是连续的，进一步降低了工作效率。

我举这个假设性的例子是为了强调，为工程师提供长时间集中的工作时间并不是偶然发生的事情。由于是您作为决定他们的时间花在哪里的领导者的职责，您需要发展一种文化和流程，以整合和最小化这些干扰，并将时间最大化为个体贡献者进行实际的工程工作。

HIPPO

HIPPO是一个常用的行业首字母缩略词，代表最高薪酬者的意见。无论你是否是最高薪酬者，你的职位都会暗示你是，大多数员工都不愿挑战HIPPO。我强烈鼓励你在讨论中尽量减少这种影响，经常给别人挑战的机会，坦率地接受错误，然后支持和倡导除自己之外的想法。当你觉得自己做得太频繁时，就说明你做得足够了。当你感到做得过多时，很可能已经达到了大多数员工需要真正相信你的最低要求。

尽管你尽力表现得易于接近和愿意被说服采用其他方法，但你在会议中的出现通常仍会对其他与会者产生潜意识的影响，尤其是如果他们在组织结构图中高于你一级。注意这种影响，并尽力只在团队真正需要你的时候参加会议。其他事情完成后，你可以获得会议结束后的备忘录/录音。

待办事项列表

总的来说，待办事项列表是一种非常简单的任务管理形式，缺乏结构、优先级或时间要素。我建议使用基于日历的待办事项列表。与将工作项目放在一个普通列表中不同，而是将它们安排到你实际的日历中。

这样做有几个优点。它为实际完成待办事项的时间预留了专门的时间，并确保你不会过度承诺时间。它可以通过移动项目来进行优先级排序，也更容易预测何时完成任务。大多数日历系统还具有内置的提醒机制，会在安排执行具体任务时通知你。

日历回顾和时间平衡

偶尔，比如每个月，我鼓励你对你的日历进行历史回顾，并测量你如何使用时间。例如，Google日历内置了分析功能，只需要对你的日历习惯进行非常小的调整，就可以提供关于时间使用情况的准确总结。在审查这些数据时，问问自己在各种活动上花费时间的比例是否符合你试图实现的目标。同时，确认你是否在用自己的优势和个人满足感方面合理分配时间也是很好的。通常，只是把这种数据以客观的方式呈现出来，就可以对组织和产生富有成效的改变提供良好的动力。

最小管理框架

作为经理，您会遇到许多常见的、重复的问题。拥有一种思维框架来解决问题可以加快决策、提高决策质量，并为解释决策提供背景和视角。以下是我在管理工作中发现有用的一些框架。

三阶段的管理问题解决

当面临一个大型、模糊的挑战时，比如接管一个新团队的管理，或者诊断和改善个人的表现不佳，我喜欢使用一个三步骤的流程。这些步骤应该按顺序进行，以制定应对特定问题的计划。

摄入信息

尽可能获得更多的信息。阅读可用的文件，无论是维基文章、绩效评估、代码还是与问题相关的任何内容。安排一对一会议，行使积极倾听的技能，并详细记录你的发现。
当您开始多次看到相同的事情，并且不再看到新的模式时，说明您已经摄取了足够多的数据。
例子：有多个人对你团队的成员的表现进行评论，经过几次积极聆听和好奇的交流后，你已经没有获取到更多有关表现问题的新信息了

综合

一旦您收集了与问题相关的足够多的数据，停一步收集信息，给大脑时间来处理。我建议至少花几天时间。尽量有意识地停止获取新信息，花时间从不同的角度看待问题。做笔记，画图，打高尔夫球，洗个澡，或者任何有助于你思考问题，并找到符合数据的可操作的分析的方法。
继续上面的例子，此时您可能会尝试为该个人的低绩效提出各种假设：他们如何花时间？是技能不匹配，期望不符，还是他们个人生活中发生了问题等等。

行动

一旦你有了一个观点，就是时候付诸行动了。在采取行动时，验证您的计划是否达到了预期的结果。如果可能的话，测试、验证，如果有必要，重新开始这个循环。

团队决策模型

有三种模式可以用来开发团队决策材料。作为经理，你可以完全独立地制定材料和决策，并将结果作为既成事实呈现给团队。也可以采取相反的方式：您可以从头开始与团队中的一部分或全部人共同开发材料。第三种方法是第一种和第二种方法之间的折衷方案：您个人开发一个草案，并将其作为一种示范性意见提交给团队，作为收集意见和反复进行推敲以达到最终版本的起点。这些技术之间的主要区别在于所需的时间和团队的参与度。我鼓励您优先考虑团队的参与度：确保团队中的每个人都理解决策，并成为该决策的支持者是确保所有人朝着同一个方向努力的唯一途径。正如硅谷产品集团的Marty Cagan所称，你希望你的团队像传教士，而不是雇佣兵一样行事。

独立模式： 作为经理独立开发所需的时间最少，但也产生了最少的团队参与度。

示范性意见模式： 从示范性意见开始共同开发决策需要中等时间，取决于执行方式，可以产生积极的团队参与度。

共同开发模式： 从零开始集体开发可以花费很长时间，但可以获得最多参与度，这些参与度来自于对开发工作的贡献。

对于任何给定的决策，你可以选择使用哪种模式，我鼓励你在选择时要深思熟虑。如果你觉得选择错误，不要害怕重新考虑。

两种类型的决策

1997年，杰夫·贝索斯在一封给股东的年度信中提出了一个框架，将决策分为类型1和类型2的决策。贝索斯写道，类型1的决策是不可逆转的，应当进行系统、谨慎、缓慢、深思熟虑和咨询的思考。贝索斯写道，如果你走进一扇门，却不喜欢在另一侧看到的东西，你就无法回到原来的地方。例如，选择使用哪种编程语言就是一种类型1的决策。

类型2的决策则相反。它们可以并且应该由具有高判断力的个人或小组迅速做出。例如，按钮使用的确切灰色色调可以是一种类型2的决策，因为可以在后续过程中轻松更改。

贝索斯的建议，我在这里再次将其传达出来，即使用类型1的决策方法来进行类型2的决策会导致缓慢和失败的实验和创新。

大部分日常的技术决策都是类型2的决策，最好能够快速做出决策，并在通过原型或MVP实施收集更多数据后进行复查或确认。这是因为大多数初创公司技术决策中最昂贵的元素是工程团队投入的时间。如果您有意识地限制了验证可逆转决策所需的时间（因此成本），那么您只会损失一小部分时间。大多数类型2的技术决策只有在你在它们之上投入了相当多的时间和新工程之后才变得不可逆转，所以在早期对进展情况进行严格评估非常重要。如果有疑问，及早做出决定以进行反转。

解决冲突

作为团队的领导者，最终你要对团队的目标负责。如果整个团队未能达到里程碑，那是你的责任。因此，在团队内部存在冲突或意见分歧时，你需要深思熟虑地参与，并准备根据以下三种情况之一做出决策：

我们会按照你的方式来做，因为你清楚而有力地证明它更优秀。
我们会按照我的方式来做，因为它更优秀，我将解释为什么，因为我作为经理有更广泛的责任范围，因此具有额外的背景信息。
我们会按照我的方式来做，因为我们无法找到任何客观原因来判断一种方式比另一种方式更好。换句话说，这是一个平局，由于最终我对成功负有责任，我们将按照我的方法进行。我将对这个决策的成功或失败负责。

任务分配的紧急/重要矩阵

在《高效人士的七个习惯》一书中，斯蒂芬·柯维提供了一个紧急/重要矩阵的框架，该框架改编自1955年德怀特·艾森豪威尔主席在一次演讲中提出的概念。在紧急/重要的二分法下，工作根据紧急性（即时间敏感性）和重要性（即影响力）进行分类。结果是一个四象限图表：

我在这里提供这个框架，提醒你考虑各种任务的价值。作为技术负责人，您经常会收到功能要求、需求优先级、缺陷等，并且有能力判断任何给定项目的重要性和/或紧急性，这是一种非常有用且快速的分诊机制。

解决人际问题

作为经理，你需要充当一个人际问题的解决者。你需要弄清楚如何帮助两个人之间高效地合作，或者指导某人改进某项技能，或者设计一个能够促进协作的团队结构。人们的行为很难预测，有时候团队成员可能说一套，但想或感受另一套。

鉴于这种不断变化的复杂性，我鼓励你像侦探或科学家一样思考：始终收集数据。假设做出某种行动的结果，然后收集关于结果的数据。有意识地去观察人们在各种情况下的反应，这将为你在未来与相同的人处于相似情况时提供有用的数据。

加入一个团队

作为技术负责人，你有两种加入团队的方式：要么从一个非领导职位开始，并逐步成长或晋升为领导；要么被雇用为团队的领导。如果是晋升为领导职位，前提是你具备良好的业务背景和证明自己的技术能力，但尚未在管理和领导力方面表现出卓越。相反，如果你被聘为领导者，你很可能在管理方面有着丰富的经验和良好的领导记录，但缺乏对组织的业务、技术和人员背景的了解。因此，你在刚开始任职时的方法应该有所不同，以弥补各自的不足。

晋升为管理/领导职位

如果你被晋升为管理职位，并且已经投入时间来发展管理技能，或者你有管理经验和良好的管理记录，那么你可能不会觉得这种过渡很可怕，你的目标将是继续在管理职位上不断进步。然而，如果这是你的第一份管理职位，那么你将面临更大的挑战。

人员管理是一套全新的技能，与让你晋升的技术技能完全不同。当然，技术技能是成为一个好的技术经理的先决条件，但远远不够。因此，了解这一点并发展新角色所需的附加技能集是成功作为管理者的关键。

如果你从编写C语言代码的后端工程师转到编写TypeScript代码的前端工程师，你可能会做什么样的事情？您可能会阅读一本关于TypeScript的书，做一些TypeScript的编码练习，加入TypeScript用户组，阅读一些TypeScript的博客等。

从编写C语言到管理人员的过程实际上比从C语言到TypeScript更大的转变。要成功过渡，您需要进行同样或更多的主动学习。对大多数人来说，成为一个优秀的人员管理者是一个终生的旅程，并不是在一个周末学到的技能。接受这个挑战，并将这份工作视为终身学习的开始。

可行的管理技巧

牢记德国总理俾斯麦（Otto von Bismarck）的格言，”傻瓜通过经验学习，我宁愿通过别人的经验学习”，以下是一些可行的新经理的建议：

寻找一位管理导师或教练。与人们讨论问题并获取额外的观点是非常有价值的。（请参阅第13页的边栏，找一位管理导师。）
学会委托。罗伯特·基根（Robert Kegan）的《免疫力与变革》详细讨论了委托的障碍以及为什么学会委托对经理的成功非常关键。重要的是要意识到，您对组织的价值已经不再限于个人输出，而是团队的输出。对于许多技术领导者来说，这是过渡中最困难的部分，但也是最关键的。
关心自己。
- 管理人员可能会感到情绪激动的压力很大。为了始终保持最佳状态，头脑冷静、积极和高效，关心自己是至关重要的。
- 找出适合自己的方式；也许是冥想、高尔夫、电子游戏或家庭时间。做任何让自己感觉良好、焕然一新并为下一个挑战做好准备的事情。
- 注意倦怠迹象，在它发生之前休息一下。管理人员无需每周工作80个小时。

查看本书末尾的推荐阅读列表，以获取更多开发管理技能的资源。

被聘为领导

如果您被雇用为团队的领导者（而不是晋升为领导职位或首次担任创业公司联合创始人的领导角色），那么您很可能具备技术和管理经验。作为现有团队的雇佣领导者，您的挑战是尽可能顺利地融入新团队，并建立与新同行的信任。毫不奇怪，我的建议是在管理新团队时更多地关注人员而不是技术。

以下是我为外部雇佣的技术负责人制定的一些短期目标，以及一些你应该尽早回答的问题。

目标：

与技术团队建立信任。倾听并在何时/以多快的速度开始产生影响或改变事物方面进行深思熟虑。
与其他团队/领导建立信任，做出合理的承诺并践诺。
了解您正在与之合作以及他们在公司/产品/技术方面的历史。
诊断团队内具有最大影响力的人员特定挑战。是否有员工的级别没有适当地界定，表现不佳或超越他们的角色？是否需要进行文化调整？及早采取果断行动来纠正文化问题，这是与团队成员建立信任的好方法，而这些团队成员很可能有意识地或无意识地受到文化问题的困扰。
诊断团队整体上具有最大影响的技术问题领域，并制定一套短期、中期和长期的团队目标。

问题：

之前是谁负责技术？这个人还在团队中吗？
- 技术负责人发现自己想成长为人员管理者是很常见的情况。如果发生了这种情况，你就会步入一个人员管理的真空。另一种常见情况是，要么之前没有技术负责人，要么他们因为业绩不佳而离职，而你现在将接手大量的技术债务。
CEO说你被聘用来解决什么问题？你认为你被聘用来解决什么问题？
当前团队之间存在什么痛点？
技术团队中哪些痛点是优先解决的？

给朋友/陌生人提供技术建议

在您的简历上有一段时间的技术领导经验之后，您可能会开始收到朋友或朋友的朋友寻求建议。在大多数情况下，我建议接听这些电话，不仅因为人脉关系很有价值，而且因为你被问到的问题可能会迫使你思考并用言语表达你内心正在潜意识中工作的想法。人们常说教别人是真正学到自己的东西的最好方法。

关于给非技术创始人提供建议的一点说明：你可能会不时地被某人自称拥有价值数十亿美元的创意所吸引。接这些电话几乎没有成本，并且可以建立一些社交/人际关系资本。然而，请注意，出色的创意本身并不代表成功的企业。在每个伟大的创意和成功之间是一个巨大的执行难题，大多数攀登者没有准备好攀登珠穆朗玛峰。因此，对于向一个有好主意但没有攀登装备的人作出承诺，要非常小心。

流量：汇流和雨伞

你可以成为一个坏漏斗或一个好雨伞。 – 托德·杰克逊，Gmail 产品经理（参见ctohb.com/umbrella 和 ctohb.com/keytogmail）

关于产品的问题、困惑和想法，在没有明确的过程指导其去其他地方的情况下，都会加到管理层。这不仅包括您在内，还包括您组织中的所有管理人员。经理们是默认的收件箱，而杰克逊的观点的关键在于，您的团队是默认的发件箱。你会听到，“嘿，X 有个BUG”，你会想，好的，Y 工程师写了那个功能，把BUG发送给他们。这是一个把输入直接引导到你的团队的例子。

更好的策略是充当一个雨伞，而不是直接让所有的输入实时到达团队，一个好的经理会组织、优先考虑，并为团队提供一个有结构的队列来处理事务。你的目标是帮助团队集中注意力，限制干扰，并为输入提供一个合适的处理地点，以便可以高效地处理。

作为经理，你很少应该直接向个别工程师强调一个错误。如果您有一个问题队列和一个处理该队列的流程，您可以基本上消除常规的单独升级。

管理层应该监控该错误队列过程，以确保队列保持在一个可管理的长度，并根据产品质量是否达到目标进行调整人员或流程。

您应该根据重要性和紧急性优先考虑您的队列。如果有一些非常重要且时间压力极大的问题出现，应该将其放入队列并优先处理。然后，根据常识决定如何处理。如果你需要打电话给某人确保他们知道问题存在，那么就这么办吧，只要这是个例外而不是规律。

你的第一个团队

作为技术负责人，你的职责不仅仅是管理技术团队，还包括作为C级人员的技术代表。你的角色是在公司的最高级别的战略讨论中代表工程和技术，并确保工程和技术沿着正确的方向发展。有时候，这意味着与其他领导者进行艰难的对话，这些对话需要脆弱和谦卑，以及有助于处理冲突，并基于相互信任。

这些对话对工作至关重要，并且为了让它们变得可能，您必须深度参与领导团队，将他们视为您的第一个团队。你很可能是一个技术性非常强的人。你可能最喜欢你的技术会议，或者至少发现与团队一起解决技术问题是熟悉而非常满足的。所以，很容易陷入这样的模式：你把大部分的时间都花在技术团队上，并采用“我的团队是技术团队”的思维模式。这是建立与技术团队之间的融洽关系的一个好方法，在某些情况下，这可能是最关键的关系要投资的。

我的指导很简单：不要让技术引人注目的东西分散你的注意力，或者限制你与非技术领导者建立的人际关系的投资。与其他领导者的关系以及与非技术同行的信任将赋予你可信度，并使你能够引导业务整体做出良好的技术决策。建立与技术团队以外的人的信任是通过良好的沟通、制定和履行承诺的期望以及在出现错误/失败时勇于承认来建立的。

技术领导者或首席技术官（CTO）如果将大部分时间花在与工程师深入代码的工作中，并几乎不参与领导团队的工作，那么当试图说服其他高级管理人员进一步投资于工程方面时，他们几乎没有可信度。或者更糟糕的是，在需要做出艰难决策时，甚至不会请他们发表意见。其他领导者将无法理解技术团队所要求的价值，或者对工程在该时刻的运作方式有何见解，并且他们将缺乏对未来可能实现的共同愿景。只有通过与领导团队的其他成员定期进行沟通，共享上下文，并在沟通过程中参与对话，你作为技术领导者才能确保领导团队对工程如何帮助组织以及它如何随时间发展有共同的理解。

与CEO合作

每个CTO和CEO的关系都是不同的，尽管有一些共同点，以及一些建立健康关系的关键先决条件。

对齐具体目标

首席执行官必须完全信任你引领技术团队实现业务目标的能力。建立这种信任意味着你需要能够与首席执行官进行良好的沟通，通过积极主动的沟通和确保首席执行官始终拥有足够的背景信息来提出好的问题。

良好的沟通意味着学会使用商业语言，并在领导层交流中避免陷入技术行话。你希望使首席执行官能够与你沟通，你使用他们的语言（如果他们不懂技术），你能从你们的交流中获得更多信息，你们之间的相处会更好。

对齐业务方向

你和首席执行官需要对公司的发展方向有共同的认识，并能够进行建设性的甚至是有争议的对话，以确保对此有深刻的理解。信任不仅适用于整体业务方向，还适用于具体目标。

有多种方式可以建立信任，但不管你选择哪种方式，你都需要建立信任。参与共享非工作活动，找到你们共享的个人价值观，并使用特定的工具和练习来建立信任（参见布伦·布朗在ctohb.com/braving上的BRAVING清单）。

对齐文化和价值观

与所有高级管理人员一样，CTO和CEO在公司文化和价值观上应该有强烈的一致性。在工程领域内建立积极的文化以及在工程领域与公司其他部门之间建立良好关系尤为重要。技术团队往往是初创公司预算中非常大甚至是最大的一项开支。技术人员的职位往往是最具竞争力的，这使得工程人员的招聘和必然的非自愿员工流失比其他部门更加昂贵。

CTO和其他高级管理人员在文化和价值观上的强烈一致性是确保技术团队感到受到尊重并在公司中得到包容的关键因素，这应该有助于人员保留。

传递坏消息

与其他领导者或高管合作的一般建议是勇敢传递坏消息给你的同事，尤其是首席执行官。由于你对团队的表现负责，你可能会有诱惑去掩饰现实，宣传一切都很好。这种做法的问题很多：

如果事情不好，也就是截止日期经常被错过或质量低于期望，你的同行会知道，并且会想知道为什么你没有对这些失败负责并解释你如何改进。现实与你所代表的方式之间的差异会破坏人们对你领导能力的信任。
有时候，你需要为软件工程团队创造一些非用户界面的工程投资，无论是技术债务还是未来架构方面。你需要获得其他领导者的信任和认可，以便其他人相信你，并理解这段时间的投资回报率。

有关拥有失败的重要性，请参阅Jocko Willink和Leif Babin的《极限领导力：美国海豹突击队如何领导和获胜》第1章的原则部分。

用你的听众的语言交流

技术主题通常具有很高的细微差别；细节很重要。技术行话在帮助传达细微差别方面做得很好，所以当工程师解释技术主题时，他们经常使用其他部门成员无法理解的语言是没有任何意外的。我相信你肯定见过过于热情、充满能量和激情的工程师试图向非工程师解释他们的项目，只得到一个茫然的表情，没有带来任何新的共同理解。作为技术领导者，你必须做得更好。

例如，如果你有一个重要的技术债务领域，并且你想在执行团队内部提倡投资整个月的时间来重新架构该代码区域，你需要以一个易于理解的方式来传达你的理由。如果你在对话中讨论延迟、RPC调用、依赖注入以及来自云服务提供商的首字母缩写，那么你的首席执行官和首席财务官几乎立即就会对你视而不见。

另一方面，如果你将对话框架定在开发人员的效率和团队士气上，并解释债务偿还与未来六个月团队速度的背景下，你的论点将更具说服力。

技术沟通最佳实践

以下是确保与非工程师的讨论和演示更成功的一些建议：

提前建立共享的语言/词汇。如果你需要使用任何高中生不理解的词汇，确保你的听众已经了解它们，或者在开始解释之前清楚地定义它们。
使用易于理解的概念。技术挑战通常与其他技术挑战进行比较，但当与非技术人员交谈时，这是行不通的。与其描述你的慢速数据传输以字节/秒为单位，不如将其与高速公路上的交通进行比较。
在讲解过程中确认理解。在解释过程中向听众提问。如果他们能在你之前说出笑话的话，那么你就知道你走在正确的道路上。
不要假设你在任何方面都因为掌握技术语言而更优越，或者更糟糕的是，因为对方对知识的匮乏而让你的听众感到自卑。“我不想对你太专业”是让听众失去兴趣的好方式。

总的来说，尽量保持你的解释简单明了。避免深入讨论可能分散注意力或使听众失去兴趣的细枝末节。

招聘和面试

有效招聘是作为技术领导者最具影响力的活动之一，也是最具挑战性的。你经常会发现自己在一个供给不足的市场中招聘人才，并与其他公司竞争，这些公司可能比你的条件更好。你的顶级候选人很可能会收到其他竞争性的工作邀请，这意味着你不仅需要验证候选人的资质，还需要说服他们你的机会是正确的选择。

在这方面，招聘既是一个销售活动（候选人评估你/你的公司），也是一个筛选过程（你/你的公司评估候选人）。在制定团队招聘流程时，每一步都要牢记这一点。

本书的这部分从团队设置到入职阶段，按顺序介绍了招聘和面试过程的各个环节。

像创业公司一样招聘

作为一家初创公司，你在招聘方面有几个关键优势，你必须充分利用这些优势，以确保你能够吸引顶尖人才。以下是给你优势的一些特点：

你的规模较小，这意味着你的工作效率应该更高，更重视人，招聘速度也应该更快，超过比你大的竞争对手。
你可以销售一个极具吸引力的公司和个人成长轨迹。你可以销售一种富有创造力和激励力的工作场所文化。
你可以卖出成功候选人将产生的影响。
你可以提供对公司的资本及其成功带来的收益进行有意义的持股。

以下是利用这些优势的一些实际提示：

在发布职位描述之前，培训并征求同事的面试意见。确保每个人都理解时间安排、面试脚本和评分标准，以及在开始之前如何使用应聘者跟踪软件（ATS）阅读和留下反馈（参见候选人供应，第59页）。
预先安排与每个候选人的所有面试。如果你的流程包括四轮面试，在开始时就把四轮全部安排好，最好在五个工作日内安排好。如果你的团队在留下面试反馈方面表现得很快（你应该坚持要求他们这样做），那么你可以提前通知任何失败的候选人，并取消任何未决的日历邀请。而将下一轮面试安排在候选人通过每一轮面试后这一做法会在每个步骤之间添加多天时间，很容易将原本可能持续一周的过程变成三周或更长时间。
一个好的经验法则，尤其是在创业公司中：没有人因为过于忙碌或过于重要而无法抽出时间与候选人会面，如果有意义的话，特别是对于更高级别的聘用。如果一个强大的候选人要求与你的首席执行官和首席运营官交谈，那么你应该安排与他们的会议。
确保每个面试官都有一个独特的脚本或指南，涵盖不同的内容，或者从不同的角度涵盖材料。（有关更多详细信息，请参见面试最佳实践中的仅问新问题部分，第63页。）

正如我在之前所说，没有免费的午餐，作为一家初创公司的招聘好处也伴随着风险，主要是形式上的。候选人几乎肯定会问你有关公司的产品市场适应性、手头现金或现金可用性、公司文化以及工作与生活平衡等方面的问题。我鼓励你在这些问题上向候选人坦诚，与你的高管团队共同制定现实的解决办法，并在被问到这些问题时提供良好的答案。

速度是你的朋友！

记住，在招聘顶尖人才时速度是你的朋友。如果你能在一个星期内完成整个过程，那么你的初创公司就比那些通常需要数月时间才能做出决定的大公司拥有一个重要的优势。

何时招聘：人数计划

现金是年轻的尚未盈利的初创公司的生命线，因此决定承诺以每年10万美元以上的费用形式新增一名工程师的薪水不应轻率行事。几个重要因素对人员编制决策起着关键作用，其中最重要的是需要、优先级、时间和预算。

职位需要/团队差距

决定招聘的第一步是确定团队中的差距。差距有多种形式。在公司早期阶段，通常是技能差距。例如，你的业务决定移动应用程序将成为营销策略的关键要素，而你的创始团队以前从未从事过移动领域的工作。当然，他们可以学习并逐渐变得有效，但雇佣一位有经验且有意愿从事移动开发工作的高级工程师来建立和维护该项目，在短期和长期上都更加高效。

其他类型的差距包括资深度差距（没有足够的资深经验来做出良好的决策，或者没有足够的初级人才来处理较简单的任务）、管理差距（一名经理负责过多的人）或专业知识差距（团队中没有人对行业的某个领域了解得足够深刻，以指导决策）。

雇佣的另一个重要理由是增加团队的总带宽。这类雇佣应该与某种业务目标或产品路线图保持一致，从而在某个特定的时间合理地增加一名新的固定团队成员。

职位优先级和时间

一旦确定了差距，下一个问题是确定这一差距需要何时填补。考虑到找到一个优秀的雇员所需的时间，确定何时开始招聘流程会是明智的。

通常情况下，答案是现在就开始！每个新的成员加入你的团队都会给你的团队增加复杂性和开销。假设你的团队不太紧迫地能够再维持六个月的较小规模，你可以延迟雇佣，这样既能降低成本，又能给你更多时间为雇佣辩护。

你的团队的请求和其他团队的请求往往会相互竞争，因此发展一个公司内共同讨论职位需求的通用语言很有用。这并不需要非常复杂；可以使用0-5的评级系统，其中0代表迫切需求，而5代表可以等待几个月或几个季度才变得迫切的职位需求。

为新员工预算

对于非盈利的初创公司来说，你应该有一个将支出与收入相对化并预测现有现金在下次融资之前可以维持多长时间的财务模型。大多数CEO和CFO对这个模型有深入而详细的了解；作为技术领导者，你不需要花太多时间来了解它。

然而，重要的是要对你的部门对这个模型的贡献保持明确的认识，这主要体现在人员编制开销（现在和将来）。该模型应提供某种程度的限制，以年度预算或费用运行速度的形式来指导招聘的时机。

招聘要求和目标

与设计软件系统一样，当你开始设计面试流程时，你应该首先考虑你的要求和目标。虽然每个公司应该和会有自己的要求和观点，但以下是我在设计面试流程时考虑的一些因素：

效率：招聘一个候选人需要多少时间和成本？
成功率：被录用的候选人在工作上表现如何，他们在公司停留多久？
候选人体验：候选人经历完整流程后，是否对你的公司有很高的评价，无论他们是否被录用？
平等机会：你是否确保每个人都有公平获得录用的机会，并尽可能避免无意识的偏见？
可扩展性：是否可以由其他人运行该过程，并且高效和成功率类似于你？

效率

对于公司来说，招聘是一项昂贵的任务。这项成本不仅包括实际开支，比如招聘人员、职位广告和招聘场所的费用，还包括时间成本，主要体现在员工进行面试所花费的时间上。在设计面试过程时，要考虑每个步骤的意图是什么，你正在进行的筛选以及实现筛选的最有效方式是什么。

减少或至少分摊时间投入的一种方法是让其他团队成员参与招聘过程。根据特定面试的主题，你并不总是需要最高级别的工程师参与面试。一个经过适当培训的招聘协调员可以像高级工程师或高管一样有效地进行电话筛选、文化面试或背景调查。

成功率

并非每次招聘都能给公司带来成功。有些人会被评估错误，有些人不适应公司文化，还有些人会在第一年被解雇或辞职。特别是在招聘规模不断扩大的情况下，你需要衡量招聘的成功率。这是技术领导者为数不多的可以计算明确、一致且有指示性的指标的机会之一，因此请充分利用并确保你的流程是一流的。考虑跟踪招聘所需的时间（从发布职位描述到新员工入职日期）、员工保留率、新员工离职率（或降级率），以及在前两年内有多少新员工被提升。

正如安迪·格鲁夫在《高产出管理》一书中所讨论的，即使是世界一流的面试流程，成功率也只有约70%。从根本上说，招聘存在许多风险：你试图根据仅有几次交谈和面试过程中收集的少量对话和数据，来预测一个人每周工作40小时，周复一周的表现如何。

最好的领导者会跟踪他们的成功率，不怕承认招聘错误，并在招聘时慢慢地进行，快速地进行解雇。

不能否认的是：雇佣一位在不久前入职但工作不顺利的新员工，对于每个人都是很尴尬和不舒服的。然而，这对于你的团队来说是负责任的做法。一些实践可以帮助提供透明度给新员工，并协助经理做出正确的决策，包括实施一个正式的90天试用期或引导期，要求新员工和经理每15天或30天进行一次检查，或者使用签订合同再雇佣的雇佣结构。

候选人体验

候选人体验是候选人在经历和完成招聘过程后对公司的感受。许多候选人在申请或面试之前都会对公司进行尽职调查。他们往往会查看在线论坛和社交媒体，看看其他经历过你面试流程的候选人或员工对你有何评价。

你不能总是控制别人对你的评价，但尽管如此，你仍希望提供那种能让候选人更愿意在线上看到好评的候选人体验，让他们亲身经历一个好的过程，并且更有意愿参加你的面试并接受你的报价。

机会平等

有句话说，人们往往喜欢雇佣和自己相似的人。这往往是因为简单而不成熟的面试评分方法仅仅依赖面试官的直觉，而直觉往往受到无意识偏见的强烈影响。这种偏见可能会对其他种族、性别、族裔等候选人造成不利影响。

在设计面试过程时，你应该基于与职位要求相一致的评分标准来评估候选人，而不仅仅依靠面试官的直觉。请参阅《面试最佳实践》第63页的避免偏见部分，了解更多关于如何避免偏见的内容。

可扩展性

如果你个人能够有效地进行招聘，那就很好。但在某个时刻，你需要招聘更多人员，而你无法亲自完成所有的招聘工作，这时你就需要扩展流程，引入其他人。为了有效地做到这一点，你必须建立一个可重复的系统，供他人利用，以便像你一样识别顶级人才，并具有与你相同的高效率和成功率进行招聘。

这意味着其他人需要能够进行相同的面试，并在面试结束时得出与你在面试中可能得出的相同的结论。

本节的目标是帮助你创建一个可扩展的面试和招聘系统，以适应你的组织目标，并能够在没有你亲自参与的情况下顺利工作（一旦你花时间校准它）。通过定义和部署这样一种结构，创建周到的文档和模板，可以使他人进行面试，并产生与你自己的排名分数非常接近的候选人。

职位描述

许多公司低估了一份优秀职位描述的价值。一份真正好的职位描述对你有两个主要作用：它帮助你在公司内部明确和统一所需角色的职责和价值，并吸引可能与之匹配的候选人。

调研市场

在开始编写职位描述之前，我鼓励你调查市场情况。看看竞争或类似公司以及他们对类似职位的职位描述。

这些职位描述通常可以提供很好的启发和校准，特别是当你在招聘一些不常见的角色时，这些角色可能不太适合你已经建立的可扩展系统。

明确角色的职责

传统的职位描述包括对角色职责的简要描述，然后是对候选人要求的项目列表。我鼓励你写更多内容。与其重点放在成功候选人在特定角色中将要做的事情上，不如思考角色的目的是什么。这个角色能够产生什么结果？你对这个角色在三个月、六个月或十二个月内的影响有什么期望？你可能不希望将这些问题的答案作为职位描述的一部分发布出去，但是深入了解期望会非常有价值。

将这些问题的答案与你的组织的其他领导进行讨论，并确保他们同意这些答案。如果在角色的职责和期望的初版上获得了重要反馈，不要感到意外。在大多数初创公司中，正式开放职位前会就具体职称进行高层次、非结构化的讨论。比如，我们需要招聘一位资深JavaScript后端工程师。编写和推广职位描述让你的团队在真正需要的时候能对公司的需求做出精确的界定，所以你可能需要进行几次修订。

职位描述作为广告

你公司公开发布的一切都是你文化和品牌的反映，职位描述也不例外。职位描述的目标是针对那种对你文化和品牌非常重要的人:你员工，现在和将来的。理想情况下，一个符合你的职位要求的合适候选人不仅会满足你的工作要求，而且对该职位和公司本身都感到兴奋。

以下是一些帮助职位描述反映你文化的方法：

加入你公司的核心价值观、使命或愿景，不论哪个在前景。
包括该角色对团队、公司和客户的影响。
宣传你的团队结构、工作环境和规模。
强调你的薪酬和福利（在某些市场上，法律要求公布薪资范围）。

除了旨在引起候选人兴趣的元素外，建议还包含一些常被忽视的细节，帮助候选人自行判断:

包括级别和薪资范围。
包括工作地点、现场要求，以及是否允许远程工作以及在何种程度上允许。
包括时区/工作时间要求。

招聘候选人

在你的组织中填补职位时，有三种方法可以来源于合格的候选人:主动招聘、走出去招聘和内部引荐。一个有效、可扩展的招聘流程应设计为利用这三种方法。

主动招聘

主动招聘是营销你的招聘职位，并收集候选人自愿申请的过程。与其他任何营销活动一样，仅凭一个渠道可能不足以产生结果。

因此，在招聘网站上发布职位描述是最低要求。根据市场情况、你需要招聘多少角色以及职位描述的质量和清晰度，仅仅发布职位描述可能是不够的。通常情况下，你需要做更多工作来吸引顶级人才，包括在专业技术社区积极推广你的职位或通过参加会议赞助等方式营销你的品牌。

没有一种通用的最佳分类广告发布平台，那些最优秀的员工倾向于将分类广告发在哪个平台上。关注行业动态，了解哪个平台/职位网站常见，并相应地发布你的职位描述。一个好的应聘者追踪系统（ATS）将对此有所帮助，因为它可以为每个候选人跟踪一个来源，并提供有关哪个职位网站带来更好/更多进入你的招聘过程的候选人的指标。特别是在招聘设计师时，与一些工作中的设计师谈谈有关最受欢迎的作品集托管网站，并在这些职位网站上保持存在，以找到最佳候选人。

你还要监控每个职位接收到的申请数量。至少，你的招聘经理们应该每周查看他们职位的招聘漏斗的情况，并相应调整他们的方法。如果一个职位没有得到足够的申请（或者吸引了错误的申请者），那就改变一些东西！尝试调整职位标题或将职位描述发布到新的渠道上。一个强大的招聘流程的关键要素与你为团队建立的任何其他流程都一样：一种谦虚的愿望，回顾过去的决策并不断改进。

走出去招聘

走出去招聘是主动联系目标候选人，并鼓励他们申请你的职位。这可以由你个人、你的团队、内部招聘人员或外部招聘人员来完成。我鼓励团队首先从主动招聘和内部走出去招聘开始招聘流程。通过真正从事招聘活动，与候选人对话，并倾听他们对你的说辞的反应，你将了解市场和顶级候选人对你所推销的东西的看法。你还会了解你的报价有多具有竞争力，以及找到与你的职位描述匹配的候选人有多容易或困难，甚至可能引导你进行调整。一旦你调整了角色，明确了你要寻找的人和要寻找的东西，你就准备好向外部招聘人员提供优化的指导了，这将有助于他们代表你更有效地寻找候选人。

并非所有的外部招聘人员都是一样的。你希望找到满足以下所有条件的招聘人员:

有很强的组织能力
能够有效地推销你的角色（你的职责是培训和督促他们做好这项工作）
积极主动地进行跟进，而不是咄咄逼人
更看重与你和候选人的关系而不仅仅是单个职位的佣金

内部引荐

招聘中的最高回报来自于内部引荐，即现有员工的推荐。人们更倾向于与目前团队成员推崇的公司做生意，并且当候选人已经通过熟悉你文化的人的审核时，更容易找到匹配的文化配对。你可以通过提供现金奖励（见附注）或与对候选人的推荐人进行良好的沟通，告知他们推荐的候选人的状态，来鼓励内部引荐。

考虑到引荐的成功机会如此之高，你应该提供最好的候选人体验。你可能还希望考虑简化（但公平的）招聘流程。跳过或压缩一些招聘初筛的环节，比如电话筛选或资格表，可能是合适的。你还可以鼓励推荐人以书面形式撰写一两段来证明他们的推荐。

关于激励引荐的数学注释

根据你可能已经拥有的数据，很容易近似计算雇佣一名新工程师的成本（包括时间和实际投入的资金）。如果考虑到引荐通常具有更高的转化率来进行雇佣，那么很明显引荐可以节省成千上万美元的费用，这可以帮助你为每位最终被雇佣并在其角色中工作数月以上的候选人提供数千美元的奖金，从而为你辩解。

面试最佳实践

面试流程决定了你能否准确地判断一个候选人是否适合你正在招聘的角色。请记住不存在完美的面试。面试官在短短几个小时内收集的数据，当然不能完全预测一个人在以后几个月乃至几年的全职工作中的表现。

在本节中，我将介绍一些高层次的面试最佳实践，然后对面试的各个步骤提供一些背景和背景信息，包括候选人/简历接收表、电话面试、文化面试、技术面试、编码任务或带回家的任务、高级面试以及最后的背景检查。

被拒绝的候选人的意见很重要

在设计面试流程时，你应该把候选人体验放在首位，作为优先事项。即使你选择不雇佣某个候选人，他们离开时也会对你和你的公司留下印象，无论好坏。这个印象可能导致他们向他们的职业网络中的人赞扬你，并有一天申请你的职位。或者，这个印象也可能导致他们在任何机会中都对你进行消极评价。

职位广告网站和谷歌评论上都有许多面试出问题的证据，一旦造成损害，要修复你的声誉非常困难。虽然对于一些候选人来说，无论你如何尊重和关心，他们都无法避免因被拒绝而产生的痛苦，但这些人是少数。对于大多数到达面试阶段的候选人来说，一个尊重和深思熟虑的面试过程将给他们留下中性至积极的感觉，对你的公司产生正面影响，并帮助你避免在线上产生负面宣传。

及时并使安排变得容易

理想情况下，你/你的团队会事先向候选人明确沟通你们的招聘流程的步骤和范围，并利用一种方便可靠的解决方案实时安排这些步骤。例如，你可以选择(A)指定一个招聘经理在工作时间内处理所有的安排，(B)提前安排好所有的面试，或者(C)提供一个在线工具，候选人可以在自己的时间内异步安排面试。

事实上，无论如何，要求每个面试官在每次面试之前都给每个候选人发送电子邮件以便按顺序安排日程安排，这可能会使面试过程拖延数周或数月的时间，都是不如其他方法的。

仅询问新问题

每个面试环节都应该给候选人一种感觉，像是对话的延续，而不是对之前会谈中讨论过的细节的重复。避免对前面的细节进行重复讨论需要在面试之前进行周密的结构化和仔细的计划。

理想情况下，后续的面试应该用于深入挖掘和探讨与候选人或角色相关的领域，双方都希望完全了解重要的优点和缺点。通过申请人跟踪系统(ATS)将建议的关注领域或新问题与后续面试者分享，可以确保连贯性、效率和候选人体验良好，从而揭示出你的潜在招聘是否真正适合你的团队。

避免偏见

如果你对无意识偏见这个词短时间还不熟悉，我鼓励你阅读丹尼尔·卡尼曼的书《思考，快与慢》。这是我了解我们大脑产生的很多种类的系统性错误的首选读物。

在不公正地有利于或不利于候选人的情况下，很容易产生一些不合理的影响。不可避免地，这将导致更糟糕的招聘结果或潜在的昂贵的法律战斗。

偏见有很多形式。大多数偏见是无意识的，可以涉及性别、种族、校友身份或社会经济背景。但偏见还可能意味着面试者在面试之前对候选人的结论仅仅基于前一个面试者的评分得分。没有一个系统可以确保消除所有有害的偏见，但是你可以采取一些措施来最小化无意识的偏见，例如在简历筛选阶段屏蔽候选人姓名或照片（这些通常暗示性别和种族）。

为了避免对后续面试者产生判断引导或偏见，我鼓励面试者在候选人对话中留下两种不同类型的反馈：

详细的笔记和评分
针对后续对话提出的建议性问题。

面试反馈的大部分应该包括对工作特定评分指南的详细笔记和评分，这些指南在面试之前就应该完成了面试问题的计划(详见技术面试，第76页)。在后续团队成员面试之前，理想情况下不应提前阅读这些反馈，以避免偏见。例如，如果你知道以前的面试者给候选人打了较低的分数，你可能会产生确认偏见，并在面试中对候选人表现不佳的任何领域重视过度。

面试反馈的第二种类型，后续面试建议，应该重点关注后续面试中需要强调或深入探讨的领域，并不会透露可能过分偏见后续面试的数据。

使用申请人跟踪系统(ATS)

当同时面试两三个以上的候选人时，管理候选人在整个流程中的安排、与面试者的沟通及时性和一致性需要付出大量的努力。如果没有一个精细调整的系统来管理所有这些安排的物流问题，候选人的体验很容易受到影响，并且招聘成本会上升。这是一个普遍存在的问题，各种价格和复杂程度的高质量现成的申请人跟踪系统(ATS)解决方案已经被开发出来应对这一问题。

这里的建议很简单：早点选择并开始使用ATS。不要等到你的流程已经乱了才采取行动。培训你的团队，要求广泛采用该系统，并与人力资源、招聘经理和面试官明确这一系统的使用要求。

推销候选人

正如前面提到的，我强烈建议招聘经理将面试过程视为销售过程。这自然会导致几个可以从销售中无缝转化到面试的良好习惯：

在与客户的销售过程中，你始终专注于向潜在客户推销产品，即使在对客户进行资格审查时也是如此。一个好的销售过程将资格审查的候选人视为漏斗，在顶部进行轻松的资格审查，逐渐变得更加细致和耗时，同时进行更个性化和定制化的销售介绍。
你应该始终向候选人推销加入贵公司及所提供的角色/机会的优势和积极效益。当他们通过你的各种面试关卡时，他们应该渴望在你公司工作，并且对选择你的工作邀请比其他他们收到的（或可能收到的）邀请更加兴奋。
确保在面试初期至少提出一两个开放性问题，询问候选人在他们下一个角色中寻求什么。这将帮助你的面试者综合候选人的期望与你招聘的角色的匹配程度。这些信息应该在候选人的资料中做记录，并在途中用来定制和调整对候选人的介绍。
- 例如，一个来自大多数初级和中级团队的初级候选人可能正在寻找一个机会，与更高级别的JavaScript工程师一起工作，以便在促进他们的成长的环境中工作。如果你的团队提供高级支持，你的文化倾向于导师关系，请确保突出这一优势，尤其是在提供阶段。
总是在面试结束时留给候选人一些时间（五到十分钟）提问。大多数合格的候选人都会带着问题来参加面试，通过他们选择提问的内容，你可以了解到他们真正关心的事情。这是你的面试者通过回答来推销贵公司好处的好机会。
在整个过程中，确保候选人感到被尊重，并逐渐接触到更多的公司信息。你最好的候选人需要感觉他们经过了智能化的审核，并且他们已经了解到了公司足够的信息以激发他们的兴趣。理想情况下，你希望即使是被拒绝的候选人也能在Google和Glassdoor上留下积极的评论。你可以通过在整个面试过程中推销公司的福利、把握人们的时间就像自己的时间一样、进行一致和及时的沟通，并确保每个人都觉得这个过程尽可能公平和透明来实现这一目标。

接收表单

面试流程的开始是一个表单，它实现了两个目标：向候选人提供一些关于贵公司和招聘过程以及其文化的信息，并从候选人那里收集一些信息，作为一个便宜但有效的筛选工具。

接收表单前言

在你的接收表单顶部，你应该概述一些关键信息给候选人：

重申他们申请的角色及其关键要求和影响。
重申贵公司的核心价值观，并提供文化的样本。
对招聘过程的期望，需要多长时间，有多少步骤，大致的流程是什么样的。

接收表单问卷

问卷应该包括要求候选人提供简历(或LinkedIn档案URL)、根据法律和人力资源要求询问与就业资格相关的一些问题，然后最好向候选人提出一些筛选性问题。筛选性问题应该是轻快的、一般性的、甚至可能是技术性的问题，以确保候选人是否适合该角色。例如，针对需要JavaScript经验的角色，用一个问题如“在不熟悉到非常熟悉的范围内，请给你对 JavaScript 工作的舒适程度打分”来确认候选人在问卷中表明的经验是合适的是合理的。

这可能看起来重复了作业说明书中列出的要求，事实上确实如此，但你会惊讶于有多少简历会缺乏基本资格。对候选人来说，这些问题很快且易答，而对于招聘经理来说，使用这些问题来筛选申请人也很快速和简单。

如果你被候选人淹没，并希望在此阶段进行更多的筛选工作，问卷中还可以包括一两个更有趣或更困难的问题。如果包含这些问题，请确保保持简短；你不希望因为问题过于艰难而在这个表单中失去候选人。如果你受到应聘者的压倒性数量，那么应该更倾向于在此处更多地增加数据来进行筛选，否则也许最好将更深入的资格要求留给更接近面试环节。

一些涵盖广泛兼容性和自我确认技术熟悉程度的接收表单示例问题（我在ctohb.com/templates上包含了一份示例）：

作为一个优秀的候选人，你会收到很多的工作邀请。在薪酬和福利相等的情况下，是什么让你选择一个公司而不是另一个公司？
你接下来的转变中，什么将决定是好是坏？
你的工作中给你提供了哪些能量？什么会耗尽你的能量？
你对地理位置的期望是什么（如地点、远程、现场）？
你对基本技术资格的熟悉程度如何：在1-10的等级中排名[相关编程语言或工具]的熟悉程度？

电话面试

初步的电话面试，就像面试过程中的其他一切一样，具有双重作用：它是了解候选人更多信息的机会，也是候选人与贵公司的人员进行第一次互动(同时也是评估)的机会。

考虑到这是候选人在贵公司的第一个互动环节，值得仔细考虑谁来进行面试。这个阶段的问题不需要很技术性，因此并不必须由技术团队的成员进行面试。通常由人力资源或专门的招聘团队进行面试。

无论谁负责电话面试，确保这个人能够很好地代表你的团队/公司文化，并且在面试阶段能提供技术候选人可能会要求的信息，包括：

软件栈的样子，包括关键语言、工具和目标客户端(例如移动端、桌面端等)。面试官在这里应该对他们使用的术语有初步的了解，而不仅仅是从列表中读出。

技术团队的规模，在公司整体上以及候选人要与之合作的人员数量。这也应该包括一般的招聘预测和每次增加多少人。

候选人应向谁汇报。对那位经理的基本背景提供一些基本背景，包括他们在公司的任职时间，也许是他们在工作之前所从事的工作。

对公司的核心价值观/文化和工作方式有了一个良好的了解。

面试官的目标应该是向候选人介绍公司、文化、角色和招聘过程。他们还将对候选人提出一些高级别的问题，以确认他们在角色方面的结构适应性。你希望候选人在这次面试中离开时对自己在整个面试过程中的表现富有动力，并对在贵公司工作的想法感到兴奋。

因此，并不是非常重要具体提问了些什么。下面是一些你可能想要涵盖的领域的大纲：

他们的招聘时间表有什么限制(例如，其他的工作邀请)？
候选人的位置在哪里, 如果需要，他们是否愿意搬迁？
大致上他们什么时候可以开始工作或者他们想要开始工作？
确认双方对薪酬期望是否一致，并解释福利/额外待遇。

除了回答问题要好，面试官还应该评估候选人是否与角色匹配。候选人是否表达清晰、是否与公司文化相符、是否履行了他们在简历上所声称的经历，并且是否对公司和机会感兴趣。

文化面试

面试过程中，你要考虑的一个重要标准就是文化匹配度。文化匹配度是指候选人的个性中除了他们的经验和技能之外的所有元素，这些元素将使他们在你的组织中取得成功。

为了有效地筛选文化匹配度，你的公司应该对其文化有一个相当明确的理解。这可以是很多事情，例如核心价值观的列表、公司使命，公司愿景或指导原则。无论是什么，它们都应该是真实并符合公司本身。

如果你对此有困惑，我会推荐你阅读《团队的团队》（Stanley McChrystal），《工作规则!》（Laszlo Bock）和《好权威》（Jonathan Raymond）。

目前，有很少一部分正式结构化的面试程序是广泛使用的。其中一个比较常规的是所谓的topgrading方法，它包括至少两个不同的东西：topgrading方法和topgrading面试。topgrading方法是一种完整的招聘方法，据说是在20世纪80年代和90年代由通用电气公司开发的，并在赫尼施的《规模化》一书中有所描述。topgrading面试（ctohb.com/interview），我称之为文化面试，是一种设计用于了解候选人背景和文化匹配度的特定面试议程、风格和结构。

按照正式设计的方式，topgrading面试将候选人引导通过他们的就业历史，并针对候选人在过去几个角色中提出同一组问题。根据候选人的经历以及他们在过去几个角色中花了多长时间，你应该覆盖从两个到五个过去的职位。你希望捕捉足够长的时间段，以努力识别趋势并观察成长，但同时也不要让候选人在面试中讨论二十年前大学实习的事情而停留三个小时。

对于每个职位，顶级投票会让面试官问以下问题：：

在这个职位上的一些显著成功或成就是什么？
在这个职位上有哪些错误或失败？你的主管的名字和职位是什么？
你认为你的主管对你的优点和缺点的诚实评估会是什么样的？
你觉得你的主管的优点和缺点是什么？

除了这种面试方式，topgrading还建议采用两名面试者的方法：一位主要面谈者，积极与候选人交流和追问；和一位专门的记录员。

无论使用一个还是两个面试者，记录笔记非常重要。为了公平评估候选人，你将希望在面试第一个候选人之前制定一个评分卡，该评分卡评估候选人的回答，寻找与公司文化的一致性。例如，如果尊重挑战是公司的核心价值观之一，可以问候选人是否能够确定任何有挑战性且尊重的情况。或者他们是否无礼地对待过以往的同事？使用面试后的笔记来完成和证明评分卡上的分数是至关重要的。

编码挑战

要求完成家庭作业，也被称为编码挑战或面试作业，是一个有争议的话题。家庭作业往往是应聘者投入大量时间的重要投资，因此是招聘渠道中应聘者流失的重要原因。很容易想象到抢手的应聘者被要求完成多个家庭作业，每个作业需要数小时甚至数天的工作，累积起来就是数周的工作。面对这些要求，可以理解应聘者会优先考虑那些他们对公司最感兴趣和/或任务较容易的作业。

尽管存在这些结构性挑战，从招聘经理的角度来看，这一点至关重要。如果没有让软件工程师为你编写代码，如何雇佣他们呢？

综上所述，有三个相互竞争的因素:

建立预测能力: 雇主希望在软件工程面试过程中，候选人能够真正编写代码，以预测其在工作中的表现。

减少流失率: 雇主希望候选人真正完成编码作业，不会在招聘渠道中流失。

改善候选人体验: 候选人希望感觉自己的时间得到尊重，被分配的任务是合理的。理想情况下，候选人通过这个作业可以更多地了解你的公司，并对你的机会更加兴奋。

预测能力

有多种编码面试或作业的形式。这些作业从有提示的带回家的项目，到使用在线平台进行编程练习（有时也称为代码挑战），再到实时的代码配对编程。在没有任何关于这些形式预测能力的经验证据时，我鼓励你设计一个练习，使其尽可能接近你公司日常工作的样子。如果你的公司不进行代码配对编程，那么在面试中评判一个候选人的编码表现，直观上来说，与是否高度相关/具有预测能力没有太大关系。至少这样可以收集到相关的信号。

作为经理，你的目标是从与你合作的人身上发挥最佳能力。为此，设身处地地回想一下你上次面试的经历，在设计编码作业时运用你的同情心。对于大多数人来说，面试是一个非常紧张的过程，在这种情况下被要求创造或解决问题并不能带来最佳表现。在编码作业上帮助候选人发挥最佳水平的一些方法包括：

在可能的情况下提供语言/工具选择的灵活性。
允许以异步方式完成工作（即带回家作业而不是实时编码）。
- 如果你的评分标准主要依赖于编码过程中的信号，以至于带回家的作业不够丰富，考虑要求候选人通过Loom或其他类似工具记录下他们完成练习的过程。
明确说明你希望从候选人的输出中看到什么。例如，如果你的评分标准衡量了候选人对代码文档的记录程度，那么确保给候选人的提示告诉他们要包含文档。或者如果你计划运行代码，则告诉候选人你只会评估正确性，还是其他因素也很重要，如性能、负面案例等。

候选人体验和流失率

如果候选人发现你的带回家编码作业有趣，并且能够轻松入手，他们更有可能完成。最好的作业与你公司业务直接相关，并最好暴露候选人在日常工作中可能遇到的问题类型。

糟糕的例子： 你是一个网络SaaS平台，而你让候选人完成一个与手机开发相关的挑战。

好的例子： 你的公司与许多传统第三方API进行集成，你的挑战是构建与真实业务具有相似领域名词/动词的Sandbox API有限集成。

如果为候选人提供拥有工作构建系统/测试的现有代码存储库来开始，可以节省候选人自己构建编译所需的时间。

为了尊重候选人的时间，建议为带回家的作业设定一个严格的时间限制。时间限制的目标并不是为了增加时间压力、迫使快速交付，而是确保候选人不会在挑战上过于投入，并觉得挑战是一个合理的要求。为确保候选人理解时间限制，你应该：

充分解释时间限制
确保规定的时间限制内任务是可以完成的
让候选人知道他们的提交将如何评估。如果你的评分标准评估候选人的README文件，那么告诉候选人他们应该花时间编写README。如果代码将与候选人一起或者由面试官异步运行，让他们知道执行时间将受到评判。如果你更关心架构决策，对运行时性能不太关注，也要让他们知道，这样他们就可以合理分配时间。

技术面试

尽管带回家编码面试的方法多样且有争议，技术面试本身更加多样。一般来说，我鼓励你遵循相同的基本原则：确保你收集到与实际工作相关的信号，并对候选人本身保持尊重和体谅。

经典的技术面试，由许多最大的技术公司采用，涉及一种形式的共享白板经验，在实时环境中要求候选人解决技术问题。这些问题从学术性的，如排序一个带有特殊条件的数组，到高层次/模糊的架构问题，如设计一个处理1亿用户发布新闻动态的系统。

对于大公司来说，经典的面试方法必须有效，因为他们每年都在使用，但我不认为它们适用于创业公司。它们往往过于笼统或过于专业，因此很难公正评分。学术问题很少与工作中每天解决的问题类型相关。

更为严重的是，它们没有帮助候选人在面试环境中取得成功。毕竟，我相信在大公司很少有工程师将数组排序算法作为日常工作的一部分。

本章概述的方法代表了我在创业环境中看到和成功使用过的另一种方法。

方法

接下来，我将介绍一种我自己在高级软件工程师招聘中使用的方法，这种方法是根据优秀人才选拔中的经验总结而来的，我将其称为技术重点面试。

技术重点面试指南

为了了解候选人的优点和不足以及这在你招聘的角色中有多重要，首先需要确定哪些主题对于你的角色来说非常重要。你可以通过创建一个技术重点面试指南来做到这一点，其中应包括四到八个技术领域的列表，以及每个领域中的一系列示例问题、最佳实践答案和评分指南。

示例答案和评分指南的目的是确保在多个面试官和候选人之间评分方面的公平性和一致性。你希望区分候选人在某个主题领域中的差距与真正的专业知识，因此你的问题应设计成能够评分：差、好和优秀。所以，它们应该使自己可以这样评分。在评分问题时，为了能够清楚区分知识差距和真正的专业知识，我建议给一个差答案0-2分，给一个好答案3-6分，只有一个优秀答案在7-10分之间。

当我说到差答案时，我指的是对所讨论的主题几乎没有经验或专业知识的回答。一个好的答案表明在这个主题上具备能力，甚至可能是非常高的水平。一个优秀的答案不仅表明在该主题上具备能力，还表明对该主题有真正的理解和深度。例如，如果问题是关于候选人如何设计单元测试套件，他们的答案是他们从未考虑过，那就是0分，表示发现了一个不足。如果他们的答案包括他们设计的一些测试套件的描述和一些理由，那就是好的，也许是5或6分。如果他们的答案包括对测试套件设计原则的全面描述，以及每个原则的优缺点以及如何在不同情况下应用它们的方式，那么这就是真正的专业知识和7-10分。

为了给候选人最好的成功机会，我建议不对每个问题都评分。相反，对一个主题区域进行评分。这样，你可以在一个主题中尝试多个问题，寻找候选人的专业知识领域，并对该主题的最终结果进行评分。

毋庸置疑，编写这些问题、示例答案和评分指南是一项很大的工作。好消息是，任何一个问题在多个角色中都有用，并且可以在很长一段时间内重复使用。事实上，我鼓励你维护一个问题的中央存储库（和相关的示例答案/评分指南）。当你需要编写下一个技术重点面试指南时，通过可以适当地从存储库中复用问题，可以让你的工作更加轻松。

参考我的问题存储库，https://ctohb.com/templates，可以了解一个例子。

招聘初级与高级员工

你在初级招聘中寻找的人的品质，比如一到两年的编码经验，应该与求贤若渴，渴望学习，以及具有扎实的编程基础逐步开发功能的初级角色非常不同。相比之下，高级招聘应聘者不仅应具备编程基础，还应对各种工具和问题的架构、观点和最佳实践有深入思考，并能够建立信任，他们不仅能够构建增量功能，还能够拥有并在新的绿地项目中做出良好的架构决策。由于这两种类型的角色提供的关键价值非常不同，因此你对它们的面试应该有所区别。

对于高级招聘，重点面试需要深入探讨候选人的决策能力，对概念的理解以及架构实践。而对于初级角色，这种知识深入探究应该更短，并且比起实际的编码练习来说应该权重更低。

面试本身

高级软件工程师的技术重点面试通常是候选人和首席面试官之间的60到90分钟谈话，最好还有第二个基本上沉默的面试官在场记笔记。根据你的重点指南的长度和想要涵盖的主题数量，你可以考虑将主题分成多个面试。

我强调这个面试应该是一次对话；你希望了解候选人在软件工程领域中最了解和最热衷的是哪些领域，以及他们从未被追责或通常委派的领域。要做到这一点，不需要脑筋急转弯、配对编程或任何问题求解。只需问一问！

面试开始时，以轻松的对话方式开始一些闲聊。一两分钟后，开始描述会议的议程/计划。让候选人知道你有一个包含面试指南的文档，并且你的目标是在接下来的60到75分钟内让候选人讨论该指南中的主题，最后留出15分钟让他们问你问题。

在开场白之后，你将转入面试指南的第一部分。在指南的每个部分中，你的目标不是问每一个问题。你首先要确定候选人在该主题领域中属于这三类中的哪一类：差、好或优秀，然后在此基础上缩小评分范围。在一个或两个问题后，你应该对如何对候选人进行分类有一个相当好的想法，然后使用后续问题进一步探究，以确定评分。

如果候选人完全不熟悉一个主题，或者承认自己对该主题不熟悉，没有必要继续问每一个问题；你已经有了评分，可以继续进行下一个。

另一方面，如果一个候选人对第一个问题非常熟悉，他们很可能在这个领域是真正的专家，但要确认他们的掌握程度，你可能需要多次提问以确保他们在该主题上提供富有见地的答案。通常情况下，要识别出掌握需要更多的时间和提问，而不是资格不符。

当你知道自己已经听到足够的答案时，不要犹豫地礼貌地打断候选人的回答，继续进行下一类别。你的目标是帮助候选人展示他们在你决定对这个角色很重要的所有话题中的技能和知识，以及在这次面试中选择了评估的内容。如果你在面试中时间不够了，让候选人留给这个机会，让他们展示在其他主题中的能力。面试的节奏管理是你的工作，不是候选人的工作。

高管面试

当一个候选人进行高级面试时，你应该已经确认他们具备你职位描述所需的技能，而且他们将适应你公司的文化。在大多数情况下，高管面试不再是高管筛选候选人的过程，更多的是候选人与高管见面并提问的机会。

但是，如果候选人申请的是非常高级的职位，或者将直接向高管汇报，那么最后一轮面试可能比简单的候选人问答更长或更全面。

参考检查

在进行参考检查时，你需要在面试过程中尽早安排，以确保它们不会成为瓶颈，并避免在不会获得录用的候选人上浪费时间。请记住，由于保护自己与参考人的关系，候选人有理由在进程的最后阶段之前不提供参考。

时间安排

因此，参考检查几乎总是发生在面试过程的最后。为了避免因完成参考检查而延迟发出录用通知，以下是一些建议：

在提供参考日期后立即并行安排所有参考人的会议。鉴于这些会议的简洁性质，最有效的策略可能是在不安排会议的情况下直接拨打参考电话。
考虑在完成参考之前进行录用。但要明确告诉候选人，最终提供要视参考结果是否达到预期而定。参考检查，假设你在此之前对筛选流程做得很好，具有很高的成功率，因此几乎不会由于参考面试未通过而撤回。
在进行参考访谈的人不一定是技术人员，因此在谁来进行参考访谈方面要灵活。但需要确保此人对电子邮件高度响应，并且在日历上有充足的时间可以安排参考访谈。

内容

一般来说，参考面试应该简洁并尊重参考人的时间和愿意帮助的态度。大多数参考面试提供的反馈从中性到积极热情不等。很少会收到明显的负面反馈，因此您的目标是快速区分中性和积极热情的反馈，确认面试过程中确定的任何优势/劣势，并继续进行下一步。如果在参考面试中收到任何明显的负面反馈，请非常密切关注并尽量获取批评的具体细节以供回报给招聘经理。

参考面试的一些示例问题:

您和候选人的工作背景是怎样的？
请评估该参考人的可靠性：您在职业生涯中管理了许多其他工程师吗？
候选人最大的优点是什么？
那时候候选人最需要改进的方面是什么？
您打分 1 分到 10 分来评价候选人在那个职位上的工作表现？
是什么原因导致您给出这个评分？
[候选人的名字] 提到他们在那个职位上遇到了困难。您能详细告诉我更多关于这个的信息吗？
[候选人的名字]在什么样的环境和管理风格下会最成功？
[候选人的名字]如何应对冲突？
如果有机会，您会重新雇佣 [候选人的名字] 吗？

发出录用通知

当您准备向某人发出录用通知时，您应该根据职位描述和面试反馈，对应聘者的级别有一个坚定的意见。从那里，使用预定的级别范围，确定工资/奖金/股权的金额应该相对简单。（有关更多信息，请参见1.4.2 薪酬和级别）。

在校准录用金额后，您应该决定如何呈现录用通知。特别是如果您的录用通知包括股权报酬，可以考虑提供一个提供背景信息的电子表格。仅凭一个股份的价值无法让候选人评估。他们需要附加的数据来评估您提供的内容，包括总股份、股价、公司最新估值等等。

我已经准备了一个示例候选人录用电子表格，网址是ctohb.com/samples。

发布录用通知

当您发出录用通知时，您需要非常销售自己。理想情况下，您已经一直在向候选人销售公司和机会，所以他们对此非常激动了。不管怎样，这对候选人来说都是一件大事，所以请确保给予这个场合应有的尊重。在解释录用通知的过程中，请保持乐观，祝贺候选人，强调您将一起度过的快乐时光和创造的伟大东西。同样重要的是，您要透明，并在最开始的时候概述所有录用通知的关键要点，特别是他们可能不期望或不习惯的事项，如股权报酬或试用期。

我建议分为三个部分发布录用通知：电话通话、电子邮件和晚餐。对于电话通话，我建议在没有事先安排的情况下给候选人打电话。此时，您已经和候选人安排了很多会议，所以没有必要再安排另一次会议增加他们的焦虑感。或者，您可以以书面形式告诉他们您打算提供一个录用通知，并从那里安排时间，但这样他们在接到消息时就无法与您进行通话了。我觉得给这个人打电话并一次性告诉他们消息更简单。

在电话通话中，您应该表达激动之情，传达录用通知的关键要点，并回答任何初步的问题。解释说电话通话之后，您将通过电子邮件发送书面材料，以帮助提供有关股权的背景信息，当然，公司将会发送正式的书面录用通知。最后，如果可能的话，请安排与候选人共进一餐，以进行更加个人化、深入的对话。

入职

对于团队中的新工程师，大多数情况下，入职不需要团队投入太大。一个优秀的工程师最终会找到方法解决问题。但是，不采取任何行动会给你的最新员工带来糟糕的体验。这会减慢他们的工作效率，并且也可能使您难以判断您的招聘质量。换言之，良好的入职优化了三个目标：

尊重员工：良好的入职体验帮助新员工融入公司文化，尽快成为有产出力的成员。
评估招聘质量：良好的入职为新员工和他们的经理提供结构，包括明确的目标，当达到这些目标时，证明他们适合该职位。
打造企业文化：良好的入职强调持续改进的文化，帮助简化未来招聘流程，并增强整体流程的可扩展性。

有很多正确的方法。以下是我自己使用过的一些相对简单和廉价的技巧和做法。请随意扩展或偏离这些想法。

童子军准则：入职

我建议您强调给您的经理、新员工和入职文件中，成功的入职事不仅取决于您团队中的所有成员，还包括最近的新员工在内。基于您招聘频率，入职文件往往容易过时。如果新员工遇到了一些不清楚、错误或完全缺失的东西，请明确告诉他们，您希望他们努力澄清并改进文件，让下一位新员工受益。

入职团队和公司

任何刚刚加入公司的工程师的入职的某些要素应该对所有员工都是一致的。这包括高层次的流程、组织文化的强调、新员工接收到的文件类型以及共享文件和设定入职里程碑的结构。例如，您不希望前端团队的入职流程非常顺利，而后端团队一无所知。第一印象很重要，入职是您确保所有团队成员对您的组织有一个良好第一印象，并以一致的方式介绍您的公司价值观和团队最佳实践的机会。

这并不意味着入职的细节将在所有团队中完全相同。当有意义时，您可以为不同的团队准备不同的材料，并且每个团队和个人招聘都应该有定制的入职计划和里程碑。

入职文件

让新员工入职的两个关键要素是教授他们公司文化和最佳实践，以及为他们提供一些结构和指导。我倾向于将这两个方面分为两个写作设备：工程指南和欢迎来到[您公司名称]工程部门，第一天指南。

工程指南

工程指南汇集了工程团队的所有意见、最佳实践、结构要素和业务运营。它应该是任何工程师学习有关预计在整个工程组织中保持一致的决策和选择的选择的单一来源。要认真思考确切地哪些实践应该在整个组织中保持一致。

您的团队越大，团队中的某些部分开发自己的专业化工作方式就越合理。也就是说，对于大多数小型/中型初创公司，比如说，小于75到100名开发人员的公司，遵循一套健康而一致的最佳实践将解锁大量的价值和效率。

指南可以采取多种形式，我更倾向于使用幻灯片/演示文稿。一些您的指南应包括的做法示例包括：

软件工程

编程语言的选择
关于持续集成/持续部署的意见和要求
命名标准（代码中的大小写、契约中的大小写）
数据处理、保护、备份、安全的标准
关于如何使用源代码控制的意见（Git Flow、GitHub Flow）
关于测试的意见（种类、工具、要做多少）
前端和后端身份验证和授权的标准模式
传输协议的标准（REST、gRPC、GraphQL等）
通用要求（我们支持移动端、响应式、翻译吗？）
认证框架及相关培训（例如PCI、SOC2、GDPR）
其他编码操作事项：访问私有仓库、linting、静态代码分析、提交消息格式/样式。

工程流程

有关节奏/仪式的意见（敏捷、看板、回顾）
有关技术文档/规格要求的意见
关于如何使用工单系统的意见（什么是史诗？我们使用故事点吗？）
全团队关注的任何指标（您在衡量生命周期时间吗？）
如何处理生产事故（PagerDuty？根本原因分析文档？）
如何将新技术纳入技术栈
关于错误和技术债务的流程。

人员管理

如何进行绩效评估，如何评估/晋升个人的期望
对入职/招聘流程的贡献的期望。

该指南应明确标注为活动文档，并制定明确的流程，以提出、征求意见和纳入指南的更改。例如，我曾经使用过一个RFC（请求意见）的流程来进行更新。

欢迎来到 [您公司名称] 工程部门，第一天指南

分发第一天指南是为新员工提供结构的机会，给他们一个清晰的任务列表，让他们在公司的第一天做一些事情，以介绍公司文化、团队成员、工作流程和软件架构。当然，第一天指南应引用必要的第一天阅读材料，比如工程指南。此外，您的第一天指南应包括以下内容：

说明如何登录/访问所需系统的操作指南，包括：

源代码控制
工单管理
任何开发/演示/生产日志记录
错误跟踪
任何设计工具（Figma、Sketch）
文档/维基（Confluence、Notion等）
内部沟通（Slack、电子邮件）
有关公司硬件的信息（包括新员工是否有选择笔记本电脑/手机的权利），以及使用该硬件的期望
设置本地开发环境的指南
团队和公司组织架构的介绍：他们的经理是谁，相关的跨职能领导者，直属下属和相关的副总裁或执行官
有关透明度以及在组织机构图中寻求帮助或升级问题的期望
技术架构的介绍
鼓励所有团队成员阅读的相关书籍、博客和其他书面资源

入职里程碑，也就是 90 天计划

正如在招聘章节中所讨论的那样，招聘很难。即使是最审慎的招聘过程也无法达到百分之百的成功率。换句话说，不可避免地会出现招聘失败的情况。

处理潜在的招聘失败的最佳方法首先是要有谦虚的态度，承认您的招聘过程并不完美，然后考虑如何测量新员工的成功并迅速采取措施纠正任何错误。入职的过程应该在新员工刚开始之前就向他们透明地解释期望。经理们应该与新员工合作，确保他们的角色是双方适合的，新员工开始适应他们的角色，并以与他们被雇佣的职位相匹配的水平工作。在六十或九十天时，新员工和经理都应该清楚地知道这些期望是否得到了满足。

如果在员工是否成功方面存在分歧，这是一个很好的迹象表明，这不起作用，您应该相对迅速地考虑是否还有其他团队位置适合新员工，或者双方是否都能得到更好的回报。

评分卡

新员工的经理应该在新员工开始之前确定和记录任何新角色的可衡量里程碑。在第一天，经理应该与新员工一起讨论里程碑，收集反馈，并共同努力制定这些里程碑，以确保它们公平并且容易衡量。对于某些角色，这些里程碑可能很简单明确，例如在支持角色中通过衡量升级工单来计算票券吞吐量。对于其他角色，您可能需要更有创意，例如交付功能或完成的故事点。无论您选择哪些里程碑，评分卡应该做到以下几点：

在经理和新员工之间建立明确透明的期望。
提供新员工的指导，说明他们在头前90天中要做什么以及如何衡量他们的表现。
为满足或不满足他们角色的期望提供明确的标准。

评分卡不必长篇大论或高度细致。关键是，不管采取什么形式，在90天之后，员工和经理都可以看着评分卡，并就员工的表现达成一致意见，并且对于这是否会成为一个良好的长期匹配有着共同的信心。

关于90天的时间长度，90天是一个常用的入职新员工的时间框架，但并不是一个硬性规定。在工程领域，30天的时间间隔通常太短，因为掌握您的技术、工具和产品需要相当长的学习曲线。相反，等待完整的绩效周期，例如六个月或一年，会让一个不太适合的人在角色中停留太久，使他们无法得到所需的改进，影响公司的时间和效率。正确的答案可能介于两者之间，确切的时间取决于您和您的经理。

处理评分卡失误

如果在90天后经理和员工都同意事情未达到期望，或者对是否满足期望存在异议，就需要进行一些变动了。这并不意味着您必须解雇新员工，但确实意味着您必须采取一些行动。在这种情况下，可以考虑以下选项：

问题出在经理身上吗？这个人在另一个团队或与不同的经理一起工作会更成功吗？
- 如果您怀疑情况是这样的，请先考虑转岗，然后再解雇。
是否存在文化上的不匹配？
- 在确定存在不匹配后，重新调整员工到您的文化并不容易，也很少成功。如果您在90天后担心可能出现这种情况，那么几乎可以肯定的是，最好的选择是分道扬镳，而且候选人很可能与经理一样松了一口气。
缺乏经验或技能吗？
- 如果你雇了一个高级职位的人员，但他们的表现只是中级水平，那么你有选择将他们调降一个级别。毕竟，如果他们的表现不符合高级水平，继续保留这个人并以高级表现者的薪酬支付给他们，对其他员工是不公平的。然而，需要注意的是，调降级别是非常具有挑战性的。除非期望值被非常谨慎地管理，否则调降级别往往会导致自尊心受伤，最终证明对团队不利甚至具有毒性。

解雇新员工

一般来说，如果在90天内不明确一个雇佣是否会成功，那么即使经过120天或150天后也不会奇迹般地变好，最好还是解雇他们。你应该像解雇其他员工一样，给予完整的离职补偿，尽可能温柔地解雇他们。

我鼓励你全权负责这次失误雇佣。如果是你雇了他们，就要承担责任；这意味着你的招聘流程还不完善。不要因此惩罚员工。一家初创公司的行业标准离职补偿是四周的工资、福利（如果你能延长）、并提供任何你愿意提供的帮助找到另一份工作的协助。

入职时间表

入职时间是从有人同意在你的公司工作并签署了录用函的那一刻开始的。你应该在他们的第一天之前就考虑如何让新员工成功。并不是每一个新员工都愿意在入职日期之前花时间学习有关公司或自己角色的知识，但根据任务或所提供的内容，许多人自愿提前学习。

我鼓励你在他们签署录用函的那一天，将 Day 1 指南和公司手册发送给候选人。如果你有一份公司阅读清单，现在是订购这些书的好时机，可以将它们直接寄给候选人，或提供电子书/有声书的格式。大多数候选人并不对在第一天之前阅读/编写代码感兴趣，但了解你的企业文化或阅读高水平的有关商业/文化/工程的书籍很少会被视为负担。你不应该要求他们这样做，但通过提供这种可能性，你可能会得到相当大的志愿参与。

在实际的入职日期上，候选人应该在早晨与他们的新经理见面并签到。如果他们在到达之前没有阅读你事先发送给他们的资料，就要设定期望，让他们在第一天上班时阅读。他们应该安排后续时间，在候选人有机会阅读介绍材料并设置他们的环境/登录后，再回顾90天绩效评估表。这也是一个很好的时机来强调持续改进的理念，并鼓励候选人对他们的入职遇到的任何小问题负责，并为之后加入团队的人改善文档和流程做出贡献。

绩效管理

提高员工士气和促进积极的工作场所文化的关键之一就是确保每个人都清楚地了解自己在工作场所中的形象，并获得可靠的指导，知道如何在组织中晋升。任何绩效管理系统的目标都是尽可能客观和公平地提供透明度和结构给员工。一套糟糕的绩效管理系统会导致令人不愉快的意外或令人尴尬和不激励的情况，而一套强大的绩效管理系统会激励你的团队，鼓励每个人同步进步。

糟糕的绩效管理通常会导致负面结果。以下是两个例子：

A 人得到晋升，结果 B 人感到惊讶并感到被落下了。当 B 人对经理挑战晋升决定时，经理无法提供具体的理由，进一步加剧了 D 人的不信任感，监察感和士气低落。

X 人在 4 级停留太久，感到恼火和沮丧，不知道如何晋升到 5 级并得到相应的加薪。

你的绩效管理系统应该给每个人清晰地说明他们的地位，在什么方面需要改进（以及如何改进），何时进行评估，以及这些评估如何影响晋升和薪资调整。

能力矩阵和级别划分

绩效管理和薪酬设计不应完全由你这个技术负责人来完成。在这方面有很多容易出错的地方，可能会使你的公司承担法律责任。通过确保你的人力资源负责人在这个过程中有很大的参与，可以避免这些问题。事实上，最好让你的人力资源负责人完成大部分的蓝图，并仅在定义技术能力方面为其提供帮助。无论由谁负责，人力资源都是你的合作伙伴。

概述

绩效管理系统的核心是一个文件、电子表格或其他可用的产物，我将其称为能力矩阵（有时也被称为影响矩阵或发展计划），列出每个职位的技能和影响领域。能力矩阵为每个技能/影响领域在不同级别上的具体表现提供了细节、特定性和期望。

例如，一个贡献个体的软件工程师的能力矩阵可能包括一个关于编码/功能输出速度的行。在 1 级到 5 级的体系中，矩阵将指定对于 1 级工程师，对代码速度的期望是每周 X 次拉取请求，或者每个迭代能够完成 Y 个故事点，具体取决于你的团队的情况。理想情况下，每个描述要么是直接可衡量并定量指明，要么是可衡量的定性条款，并由团队以一致的方式解释。对其他级别的期望值会逐渐增加，并在 5 级达到一个非常高的编码速度要求。有了完整的能力矩阵，任何给定的团队成员都应该能够在每个类别中排名自己，并生成一组排名与经理或同事提供的排名非常相近的排名。

一旦你写出了每个级别的描述，剩下的就是发布一个公式，将个人技能的排名总结为一个工作级别。有了这个，你就拥有了一个透明、客观、可衡量的系统，任何员工都可以用来了解他们在工作中的表现，以及他们可以在哪些方面改进以提升水平。关于这个总结过程的示例公式，我在《绩效评估》第 101 页中提供了一个样本。

请记住，不同的职位应该根据团队的不同贡献进行评估，应该有不同（虽然可能有重叠的）能力矩阵。特别重要的是，需要为管理职位创建一个单独的矩阵，以区别于个人贡献工程师，鼓励管理者在编码以外的能力上成长。

创建能力矩阵

能力矩阵的细节涉及到团队的每个成员，因此很明显，团队应该参与制定这些细节。参考《小型管理框架》第 33 页的团队决策模型部分，这显然是适合该模型（straw man 或 codevelopment）的工作。

我建议使用 straw man 模型：首先概述你想要在任何给定角色中看到的关键技能和影响领域，并尝试填写大部分能力矩阵的表项。然后向技术团队介绍这个想法，并让他们知道你希望他们对如何完善第一稿提出意见。将固定的时间作为团队的时间，并鼓励团队一起讨论矩阵，可以使用分组讨论单个类别。

无论你选择哪种结构，请让它明确，至少提供几个小时的保护时间来进行工作，并设定截止日期，以便接收最终反馈并整合成团队的候选终稿。

最多应该有五个一般类别，每个类别至多三个具体领域。超过大约十五个技能/影响领域会使矩阵过于复杂，无法作为一种有效的绩效评估工具使用（并且肯定对于及时收集团队反馈来说也过于繁琐）。

每个级别的评级系统和绩效期望应该被清楚地描述说明，或者在适当的情况下与相邻级别共享描述。

我在我这本书的网站上提供了一个示例的晋升计划，网址是 ctohb.com/templates。Codeacademy.com 也有一个很好的模板，网址是 ctohb.com/competencies。

薪酬和级别

我建议将薪酬与能力矩阵级别系统挂钩，因为这样做可以优先考虑两个目标：公平和激励高绩效。

关于公平，如果同一职位和级别的两名员工薪酬相等，那么这种薪酬的公平性将取决于级别的公平性。如果整个团队参与和相信能力矩阵的公平性，那么他们大体上也会相信与该矩阵挂钩的薪酬是公平的。

至于激励高绩效，将薪酬与级别挂钩在经济上激励每个人提升水平。如果能力矩阵设计得好并且民主的话，你的团队将专注于实际帮助业务的技能/影响领域，这将为他们赢得更高的级别（和更高的薪酬），同时加速你的团队发展。

将级别转化为公平薪酬比大多数人可能想象的更微妙。最简单的方法是创建一个透明的电子表格，其中李斯特 X 级的所有人每年获得 Y 美元，但这种严格的制度会引发一些问题：生活成本调整（也称为当地费率）和非绩效奖金。

GitLab 在一篇很好的博客文章中解释了为什么他们支付当地费率（参见 ctohb.com/local）。他们的薪酬计算器也是公开的，网址是 ctohb.com/gitlabcompcalc。然而，如何处理当地费率并没有一个正确的方法，你应该考虑支付它是否对你的业务有意义。如果合适，以一种透明和数据驱动的方式计算这些费率。

让级别对应于特定的薪酬范围，而不是具体的薪酬金额，可以解决许多薪酬问题。每个职位都会希望校准到市场水平，但市场水平是如何确定的？一般来说，用于确定市场水平的工具和数据会有一定的不精确性，最好只能给出一个误差在 10-20% 范围内的范围。之所以不那么精确，很简单：你公司的软件工程角色可能不会与其他公司的相同角色在要求上完全相同，毕竟你的代码库和工具不完全相同。

拥有一个薪酬范围还留出了在绩效管理系统之外提高薪酬的空间。非绩效调整包括按工作年限增加工资和通胀调整。你还可以将薪酬范围视为一个粗略的代替，并为生活成本调整留出空间，然后再制定一个更复杂的当地费率系统之前。

竞争性费率和市场价数据

因此，你已经设计好了你的能力矩阵，并决定将级别转化为薪酬范围。现在，你只需要计算你的薪酬范围。这是一个你肯定希望你的人力资源主管与你密切合作的领域，以确保你符合可能存在的任何法规要求。定义薪酬范围应尽可能地基于数据，并且由于一些现有平台的存在(无论是付费的还是只需要数据分享的平台)获取这些数据相对比较简单。像Pave、OptionImpact by Advanced-HR、Levels.fyi和Glassdoor这样的平台可以提供丰富的数据集，可以根据公司的规模、形状和阶段进行过滤，以确定特定角色的相关薪酬范围。

职位标题

很多创业公司的创始人会告诉你他们的组织结构非常扁平，职位标题并不重要。这在某些情况下实际上是真的，但这只是例外，而不是常态。在绝大多数公司，创业公司包括在内，有关职位标题的使用有一致的趋势。分配职位标题会为级别和责任范围创造期望。职位标题容易授予但很难撤销，因此在为职位描述或晋升确定职位标题时值得考虑和体贴。

对于非管理角色，在决定标题之前，我首先鼓励你使用数字来确定你的级别，例如 Level 1、Level 2 等，通过能力矩阵 (请参见《能力矩阵和级别划分》第 95 页)。一旦你知道每个级别可以期望什么，你可以将级别转化为职位标题。不要担心给职位标题加上数字后缀；使用像 Junior Engineer 1 和 Junior Engineer 2 这样的标题更容易和更清晰，而不是发明一个新的形容词，表示比初级稍有经验但还不是中级的意思。

工程个体贡献者职位标题

针对个体贡献工程师的职位标题非常直观，使用描述性形容词来传达资历和责任的大小。大多数创业公司会使用以下主要三个职位标题：初级、中级和高级工程师。除了高级之外，常常还使用 principal、fellow 和 architect 等词汇，尽管这些词汇的定义和层级不太一致。

高级个体贡献者通常拥有技术负责人的非正式职位。技术负责人意味着个体贡献者的一部分时间花在管理风格的职责上，但他们的主要职责仍然是进行工程工作。很少有人将技术负责人的概念放在简历或组织图的职位上；它只是对高级员工的一项附加责任，在这个职位上的资历被期望在技术方面非常高、经验丰富、擅长人员管理、沟通和战略思考。

管理者职位标题

管理者的职位标记比个体贡献者更有细微的含义。最常见的职位标题是软件开发经理 (SDM) 或软件工程经理 (SEM)，具体的级别修饰，例如中级软件工程经理或高级软件工程经理。SDM 或 SEM 通常负责一个工程师团队，这些工程师团队又负责一个特定的功能或产品。

下一个级别通常是工程总监。总监负责单个或高度相关产品中的多个团队的表现、协调和输出。在大多数组织中，总监不能被视为一种战略角色。换句话说，总监没有制定技术方向或产品策略的期望。

总监之上是工程副总裁 (VPE) 的角色。VPE 的实施方式并不是通用的。它既可以作为公司所有工程师的组织负责人（代替 CTO），也可以作为跨产品领域的战略技术负责人。有时 VPE 向 CTO 汇报，有时向 CEO 汇报。然而，VPE 的共同点是对技术的高级别、经验丰富和具有较高的人员管理能力，以及出色的沟通能力和战略思维能力。

绩效评估、调研和晋升

不是一个竞争力矩阵中的所有技能领域都可以由经理或电子表格定量评估，因此每个团队都需要一种绩效评估流程，该流程也可以从经理和同事那里收集定性反馈。

具有挑战性的问题是如何以一种可以与你的层级对齐的方式收集定性反馈。在本章中，我介绍了一种我用来收集反馈的方法，最终可以产生一个相对容易理解的评分系统，可以生成个人绩效级别。

绩效评审周期

绩效评审需要大量时间，可能会让人筋疲力尽，对你的团队来说成本也很高，这些都会导致管理层不那么频繁地进行绩效评审。竞争的激励是员工希望得到更紧密的反馈循环和更多的晋升机会。平衡点在于每六个或十二个月安排一次评审（更即时的反馈可以在定期的员工/经理一对一会议中进行）。请记住，评审之间需要足够的时间让个人成长和展示成长。通常，六个月是平衡这些关切的下限。

评审人选择

“谁评审谁”这个问题没有简单的答案。许多公司只让经理进行评审，就这样而已。尽管经理的反馈是有价值的，但也可能给偏见留下过多的空间，并忽略了同样重要的同事和直接下属的观点。运行一个公平全面的流程最简单的方式（尽管稍微费用略高）是让每个员工接受包含这些其他观点的多次评审，通常被称为360度评审。

在这里，我推荐使用稻草人技术（参见《团队决策模型》一节）：每个经理应该创建一个直属下属和有足够接触该团队成员的同事列表，以编写有价值的评审，然后与员工进行一次对话，听取反馈后再最终确定列表。经理还应该记录每个员工被要求完成的评审数量，以确保请求可行。

评审问题

你的问卷应该与你的竞争力矩阵相呼应，鼓励评审人明确参照矩阵。

相同的一套问题可以适用于每个矩阵类别：

这个人在这个领域有什么出色的例子？
这个人在这个领域表现出改进的空间在哪里？你认为这个人在这个领域的表现水平是多少？

请注意，从无意识偏见的角度来看，最好是在要求评审人确定例子之前先要求他们确定水平。否则，会鼓励评审人选择一个水平，然后挑选例子来证明他们已经选择的水平。

在结尾时，可能有必要包含一些更高级/更柔和的问题：

你有多么渴望和这个人一起工作？（范围：一点都不渴望到非常渴望。这个问题来自Netflix的“保持者测试”[ctohb.com/keeper]）
这个人目前在X级别。你觉得他们准备好晋升到X+1级吗？
有没有其他优势你想强调的？
有没有其他需要改进的领域你想强调的？

评审形式

你可以使用正式的评审工具（也称为绩效管理或文化管理工具，如Culture Amp和15Five）进行评审，也可以不使用工具。当然，定制的工具可以节省时间并快速为更大的团队扩展此流程。关键是确保所有个人反馈都是匿名的，除了指出来自管理的分数（我们将与后续的同事评审分数分开使用，作为对等评审的一种检查）。

结果计算

一旦评审提交完毕，每个人在竞争力矩阵的每个类别中应反映出一组得分，最好将同事、直接下属和经理的分数分别列出。下面是得分矩阵的一个示例：

<TODO：在此处插入表格>

现在的挑战是如何将这些分数聚合成最终的工作级别计算。该计算中的一些关键考虑因素：

保护流程的完整性（例如，员工没有与同事合谋以人为因素人为地提高或降低任何人的分数）
确保公式公平且可以一致计算
确认经理对员工的影响的观点与同事/下属的反馈是否一致
决定矩阵中的所有类别是否权重相等或不相等。

以下是我推荐的一种确定级别的方法：将级别分配给累积得分达到66％或更高的水平。给定级别的累积得分是该级别或更高级别所有分数的百分比。最低级别的累积得分始终为100％，第2级将为100％减去第1级的得票率。第3级是100％减去第2级和第1级的百分比，依此类推。

在上面的示例中，这个人的级别是2级。在2级，他们的累积得分是90％。根据66％的规则，他们与3级非常接近（60％），只差两票。他们如此接近可以在教练中用于鼓励在晋升之前进一步改进，或用于证明在薪资带内进行调整的合理性。

当你完成整体计算时，如果你成功追踪了经理分数，你可以将相同的公式应用于经理分数，并计算经理评审的累积分数水平与所有同事评审的累积分数水平之间的差异。如果存在较大的差异，即超过一个级别，那就需要密切关注并进行额外的审查，因为这意味着经理和同事在个人绩效方面有显著不同的观点。或者可能表明在投票/评分过程中存在某种异常。

结果讨论

我鼓励经理在实际的一对一绩效评审会议之前提供绩效评审数据，以最大限度地提高会议本身的价值。最好是提供给个人数据并给他们一些时间来处理，这样在会议发生时他们可以全身心投入。

绩效评审会议的议程应简单：

讨论在预期之外或通常不会在一对一会议中涉及的任何优点或弱点。
综合列出一个小的关注领域列表，在下一次评审周期之前努力改进。很多领导者主张只有一个关注领域，但我看到有几个人在给定的时间内在多个方面都有成长，所以设定两个或三个关注领域是合理的。
安排经理和员工定期检查这些关注领域，并确保在下次评审之前有进展。

薪酬调整发布

在许多公司，评审反馈和薪酬变化会在不同的时间进行处理。我认为，在绩效评审会议中讨论薪酬变化并不重要，甚至不具备优势，因为这可能会分散注意力，而本可以是一个艰难但重要的讨论。关键是在绩效评审流程之前设置对薪酬变化的期望，包括决定、沟通和实施的时间，这样他们在进入会议之前就知道会有什么期望。

绩效改善计划（PIPs）

绩效改善计划，通常称为PIPs，是一种为提高员工绩效或解雇员工提供结构的工具。PIPs的几个关键方面包括：

你的团队每个人都应了解公司的PIPs流程。
很多人上班时都会心中充满了相同的焦虑问题：我今天会被解雇吗？或者我表现得足够好吗？
知道公司有一个包括纠正机会的解雇员工的正式流程可以帮助减轻这些焦虑。
只有在真正试图解决并改善表现不佳的情况下，才应使用PIPs，因为这要求员工和经理都付出了很大的努力。
经理应该花时间仔细完成PIPs文件，确保清楚地说明表现不佳，提供定量、清晰的评估标准和结构，同时提供支持和指导来帮助个人改善。
PIPs应该允许合理的时间来展示改进，比如给予个别员工30天的时间，高级员工或经理给予60天的时间。

PIPs应该始终包括一份完整的书面版本，不仅可以确保员工和经理之间的清晰沟通，而且可以为人力资源/法律部门提供文件，以备后续查询。

有一些情况下你应该跳过PIPs流程直接解雇员工：

公司政策中的违规行为、人力资源违规行为、不当的工作场所行为等，这些都不能通过PIPs来纠正，应该采取零容忍的态度。
某些技能差距无法通过PIPs来纠正，比如在某个特定领域缺乏判断力、不适应公司文化或在关键技能领域缺乏经验。这通常是对管理层或非常高级的职位考虑，其中良好的技能判断对角色至关重要。

更改岗位

在制定PIPs或解雇表现不佳的员工之前，问一下自己是否该将这个人安排在公司的另一个团队或角色中。如果表现不佳的性质是基于技能的，并且员工在不同的角色中应用这些技能可能会更好，那么改变团队可能非常有成效。如果表现不佳是基于文化的，那么你很可能会发现双方都没有动力尝试内部调任。

优秀的臭名昭著

“优秀的臭名昭著”是一个行业标准术语，用于描述那些在个人自身非常高效，但却会损害周围人士士气或生产力的人。他们经常被描述为有毒的个性。

由于他们有时具有非凡的个人生产力，选择解雇优秀的臭名昭著人在情感上可能很困难或不正确。几乎普遍的建议是无论如何都要解雇他们。作为经理，你允许有毒行为继续存在的每一天都会增加团队对你允许其继续存在的不满。没有任何个人的生产力能够弥补对公司文化和作为经理的信誉的打击。

解雇

你的公司应该有一个明确的程序来解雇员工。我最好的建议是：遵循它。如果处理不当，这个领域可以对公司构成重大责任。关键考虑因素包括：

文件记录：确保你有足够的记录来证明解雇这个人的决定，并证明解雇是基于绩效或其他正当理由。

时机：一旦你决定解雇某个人，尽快行动。普遍的经验是，在解雇某个人之后，经理通常不会太担心他们是否应该解雇这个人，而是担心自己是否等待得太久。从机械的角度来说，决定在一周的哪一天最好解雇某个人并没有太大的区别，但如果你能够将其保存到下个月的第一天而不是最后一天，那么你就能为员工提供额外一个月的公司医疗保险计划的好处。

见证人：确保经理和人力资源部门在实际解雇会议上作为见证人。会议应该非常简短，言之凿凿，人力资源部门应该回答关于解雇后续事宜的大部分后续问题。

离职处理：在解雇之前事先制定一个计划，以确定何时关闭员工对公司系统的访问权限，并取回任何公司硬件。

离职费：解雇员工通常不仅仅是公司/管理层的失败，也是员工本人的失败。解雇某人并不是一个显示恶毒或小气的地方；那个人已经在你的公司投入了时间和精力，你应该尽一切努力为他们在下一个角色中取得成功，包括提供行业标准的离职费（范围有些广泛，对于个人员工来说，几周，对于高级执行人员来说，两三个月，离职费通常也考虑到在职时间）。

团队组成

初级人才和高级人才之间影响的关键差异在于他们能够可靠解决不同类型问题的一致性。随着工程师经验的增加，他们在不断扩大的范围内的判断和决策能力也在逐渐提高。同样，你应该期望更高级的人才能够提供缺陷更少、更持久且更能适应需求变化的解决方案。这并不是说每个人都必须是高级的；事实上，在大多数项目中，很少有人涉及到构建全新的领域解决方案。

任何给定团队的正确组合应根据要完成的工作类型进行考虑，并相应地有意识地安排团队的组成。

高级人才构成

如果你的代码库：

从上述角度来看，你的团队应该更加侧重于拥有高级工程人才：
是非常新的，需要大量的架构和基础契约的创建；
是非常旧的，维护较差或考虑不周，被认为很难工作，总而言之，是一个老旧的代码库；
正在重大变更需求中，尤其是新需求看起来与旧需求非常不同；
使用了新工具、技术或模式，需要验证适用于你的问题；
需要建立新的模式/工作方式，特别是在没有提供明确保护措施鼓励健康模式的生态系统中。

技术专长

在大多数初创公司的第一天，团队通常由一小部分工程师组成，通常是两三个人。只有三个人的团队机会有限，无法进行专业化。有二十个技术工作类别要完成，只有三个人，所以根据鸽巢原理，至少有一人，而更可能是所有三人，都会做许多类型的技术工作。换句话说，公司刚开始时，每个人都要承担多个技术角色。随着公司的发展，团队人数的增加，你和你的员工会发现更多专业化的机会。

那么，在你筹集到融资并首次扩大团队时，你如何决定是否需要前端工程师、后端工程师、DevOps工程师等？以下是一些一般性的指导原则：

倾听你的团队：目前从事工程工作的人很可能会表达出最大的低效率来源以及最需要帮助的地方。作为经理，你的工作是接纳这种观点并进行推演。这是团队指出的两个月后可能消失的问题，在这种情况下雇人并不合适吗？还是这个问题在本质上具有系统性，可能在长期内持续存在？

寻找影响生产力的因素：如果你的团队大部分是前端工程师，而你在后端可靠性上遇到困难，那么这就应该是你需要后端或DevOps工程师帮助的信号。相同的原则适用于测试、开发者体验等等。规模化专业化： 在团队规模超过十几个人之前，很有可能你最好拥有一个以全面专才为主的团队。

根据初创公司的经验，以下是一些团队构成的大致数字：

团队规模1-5人
- 你的团队都是全面的专才，最多只在前端、后端和移动端之间进行专业化。
团队规模5-15人
- 你的团队根据产品或一般技能领域进行专业化，如后端、前端架构、前端设计、DevOps和测试。
- 当你的工程师数量超过15人时，你可能需要开始考虑在测试和DevOps方面投入专职资源。
团队规模15-30人
- 到这个阶段，你应该有真正的专业化，并且只雇佣在软件工程子领域有专长的人。
- 在这个阶段，工作效率方面的任何低效都可能在整个团队中变得非常昂贵，所以确保你要么增加人数，要么花时间确保开发人员能够完成工作，他们的工具正常工作，并且操作流程得到简化。
团队规模超过30人
- 在这个阶段，有许多方法来将团队拆分成较小的单元，以确保工作保持高效。如果你有多个产品线，将团队成员与特定的产品线保持一致是一个相当自然的组织起点。
- 在这个阶段，许多公司使用“Pods”概念，其中一个Pod具有一个关注领域，并由能够独立执行该领域任务的多样化/跨职能团队组成。

项目维护：两个小组的理念

如果你在开发面向终端用户的软件，你的工程团队必须在做新工作和处理来自活跃客户的支持票务之间取得平衡。如果不加以控制，处理支持票务的需求会分散团队的注意力，影响效率，消耗士气，并使最优秀的员工筋疲力尽。解决这个问题有很多正确答案；重要的是你认识到其对团队的影响，并为他们设计一个解决方案，以提高工作效率和为客户创造良好的结果。

微软在这个主题上发表了一篇很棒的文章，题为《构建高效团队》（ctohb.com/teams）。该文章描述了他们所称的两个小组模式。这个模式概述了目标小组和客户小组。

目标小组专注于未来，开发新功能。客户小组专注于现在，处理活跃客户的问题，诊断错误，并优先处理站点运行状况。

客户小组的其他名称可能是维护团队或二级支持团队（一级是你的非技术客户支持人员）。

将维护工作分配给专门团队有很多好处：

这样就可以有一个专门的团队随时监控客户队列，及时处理重要和紧急事项。
这样你的目标团队就可以专注于未来，不受客户支持工作干扰。
这样可以在客户小组内部发展专长，构建工具和专业知识，使问题处理随着时间的推移变得更加经济高效。
对个别工程师来说，尤其是初级工程师，这提供了另一条职业发展路径，使他们在团队上能够学习和提升。

关于两个小组方法，我经常被问到的第一个问题是：一个人在客户小组停留多长时间？有四种确定客户小组任期的方法：

将客户小组作为一个长期的独立团队或部门。
- 你已经发布了重点放在支持和调试上的工程师职位描述。注意，对许多工程师来说，仅关注调试的工作可能听起来不太理想。对我来说，强调数据录入或会计的工作描述听起来非常讨厌，然而有许多人喜欢甚至追求那些工作。
- 不要假设只因为你不会做那份工作，就没有其他人可能对展望兴奋。特别是，作为客户小组的一员，一个工程师将接触大量代码，通常有机会与客户交谈，而且压力不那么依赖产品驱动，这些事情或许会对合适的候选人有吸引力。
为工程师指定明确的职业发展路径，开始在客户小组工作，并在一段时间后（通常是十几个月）转移到目标小组。
工程师定期在两个小组之间轮岗。微软上面引用的博客文章建议在两个小组之间不断交换一些团队成员。
将客户小组定义为临时团队。这可以意味着客户小组本身并不全职存在（也许每月只有一周），或者团队成员不断在客户小组和目标小组之间轮换。

我建议只为需要团队专门处理客户问题的团队或产品创建一个专门的、永久的客户小组。如果你在一个高度支持型的业务中，一个专职客户小组可以成为工程生产力和客户满意度的乘数。

团队组织

一般来说，技术组织结构图分为两种方式：功能组织和产品组织。功能组织是按照团队成员所从事的工作类型进行组织，比如前端工程、测试或特定的内部服务。产品组合，有时被称为业务单元，是围绕特定的业务/产品重点进行组织，比如企业核心应用程序团队或消费者移动应用程序团队。你如何选择组织你的团队对团队的合作、生产力和士气有着重大影响。以产品为组织的团队，通常被称为Pods，在大多数情况下是正确的答案。

当你设计一个组织结构图时，你应该考虑你要优化的是什么。对于初创公司，组织结构图的主要目标是确保需要紧密合作的不同团队之间能够通过组织结构来实现并鼓励合作。实现这一目标的最佳方法是将所有直接参与产品可行性和成功的人组织在一起，并对他们负责实现共同的目标，并在产品上形成共同的所有权感。

当你的团队很小，只有一个产品时，如何组织的问题是无关紧要的，因为你的团队是一个跨职能团队，所有人都在为同一个产品工作。当你的团队扩大到12人或更多时，你需要开始更加有意识地定义什么是一个Pod，并找到一种易于理解并与你的产品实际情况相关联的方法，然后才能将你的团队分成Pods。

Pods的优点是更强的团队凝聚力、自主性所有权、责任和整体执行速度。然而，这种方法并非没有权衡。让一组工程师长时间在一个产品上工作可能会形成知识壁垒。随着组织的规模扩大，产品团队更有可能做出可能在局部优化但导致重复工作或计算资源浪费的架构决策。如果你预计并计划应对这些问题，那么当这些问题得到很好的管理时，带来的痛苦远远大于自主、高效的Pods带来的好处。

管理远程团队

有足够数量的成功的百分之百远程软件工程团队表明，远程组织可以运作。这并不意味着所有远程团队都会成功，或者构建一个完全远程的文化一定容易。我管理远程团队差不多十年了。以下是一些建议，适用于大多数远程管理场景。

文件资料

远程工作意味着没有人坐在你旁边回答问题，但这并不意味着问题会消失。那些问题仍然会被问出来，只是现在社交环境消失了，所以问题可能要等一段时间才能得到答案。或者，现在问题会立即提出，引发各种通知，分散注意力，打乱专注的工作。拥有一套完备的内部文档以及有效的搜索功能可以加快回答问题的速度，并减少一对一上下文切换的次数，这些切换可能会成为完成工作的障碍。

异步工作

将远程工作变为一种资产而不是负债的一个好方法是采用异步工作方法。强调异步的文化减轻了时区不匹配的负担，并减少了在远程会议/处理远程上下文切换上花费的时间。（有关异步沟通和异步工作的更多信息，请参见“超沟通的好处”部分，第20页。）

面对面聚会

虽然视频通话非常有用，但无法取代团队一起用餐的感觉。通过面对面会议形成的联系往往持续很长时间，因此即使是偶尔进行面对面会议的投资，也可以在几个月内改善团队成员之间的社交关系质量。作为一个一般规则，一个团队每个季度至少应该面对面聚会一次，以保持这些关系，并最大程度地减少远程社交上的沮丧感。

时区重叠

我总体建议，对于在同一个项目上工作的团队，应该确保至少有四个小时的工作时间重叠。这给定了足够的时间窗口进行常规安排的会议，并提供了进行即时对话和提问的机会。

创造社交机会

一般来说，人们在视频通话中的默认模式是在通话期间同时处理多个任务，然后尽快结束通话。一旦工作对话结束，每个人都挂断电话。这与人们在现实生活中的互动方式不同；例如，会议结束后，你们在走回座位的路上在走廊上谈论运动。会议结束前/后的这段社交时间是人们建立关系和信任的宝贵方式，如果领导层和企业文化积极支持，这种社交时间是不会发生的。一个经济实惠且简易的方法是经常提出一些轻松、轮流发言的破冰问题，比如你可以分享一条个人和职业上的好消息是什么？

你可以通过远程欢乐小时、虚拟团队晚餐和社交活动来支持远程社交建设。在COVID-19之后，现在有许多在线社交活动组织者举办远程活动，范围从数码赌场之夜到虚拟逃脱室。

打开摄像头

根据你阅读的文章，70-90%的沟通是非语言的。在视频通话中使用网络摄像头虽然不能取代这70%的所有情况，但无疑比完全没有视频要好。现在网络摄像头这么便宜，也没有什么理由不在你公司具有远程设置的情况下添加这一补充社交沟通带宽。普遍的反对意见是员工担心别人可能会对他们在摄像头上的外貌进行评判。如果你面临这样的顾虑，我鼓励你为希望以最高质量远程沟通的商业理由，以及对于对他人的外貌做出不恰当评价的零容忍政策进行强调和审视。创建一个让人们准备好自己的空间也是有帮助的，比如允许/鼓励背景模糊以及偶尔关闭视频以处理现实中的问题或整理一下。

录制会议

录制会议提供了一种很好的方式，让员工在没有日程安排的会议期间快速了解一个主题。一般来说，你会发现很少有员工或候选人反对录制视频通话的想法。录制也是一种很好的方式，可以让更多的人了解到一些内容，而不仅限于当时的舒适范围。例如，你可能希望让由四五个人组成的招聘团队观看一次与候选人的面试，但在当时让五个人在房间里可能会让人感到压力，此时录制一次一对一面试是一个很好的方法，可以确保每个人都有机会在不会过多压力或不公平的情况下评价候选人。

领导责任

作为一名高管，你的领导责任超出了开发和培养一个工程团队的技术组成部分。你应该致力于帮助公司整体取得成功，特别关注技术如何为成功做出贡献。这意味着要关注技术与公司其他部门的协同工作情况，促进与内部和外部的其他团队之间的良好合作，以及制定有关技术和产品开发的良好流程和管理实践。

产品和设计团队

作为技术领导者，你有责任确保你的工程团队与产品和设计团队高效合作，即使这些团队向其他人汇报。在设计这个流程时，作为一般规则，将事情在不同团队之间扔来扔去是低效的。良好的产品、工程和设计团队之间的互动需要共情和理解。你要了解其他团队做什么、面临的挑战是什么，以及你和你的团队如何使他们的工作更容易。下面我将介绍一些关于这些其他职能的背景知识，并提供一些建议，如何高效地协作。

设计系统

设计团队理想情况下希望软件工程团队能够忠实、完美地实现他们的设计。但在没有任何结构或约束的情况下，实现像素级的完美可能很昂贵，甚至是不可能的；然而，专有的共识和设计系统可以大大降低这个任务的成本。

设计系统是一套管理可重复使用组件和模式的设计标准，以实现规模化的设计。大公司往往会创建自己的设计系统。例如，Atlassian将其设计系统公开提供（ctohb.com/design）。作为一个小型初创公司，在设计系统上进行创新可能并不是你成功的关键，因此你应该使用现成的设计系统。如今，你可以选择许多现成的具有丰富功能和各种审美风格的设计系统，很可能可以根据你的品牌进行定制。

设计系统不仅提供一组省时的规范和设计师使用的组件，而且通常还提供了对各种前端语言和框架的直接支持。例如，Material Design在Figma中有一个已发布的设计系统（ctohb.com/figma），以及一组JavaScript React组件（mui.com）和Angular组件（material.angular.io）。

通过采用像Material（或AntD、Chakra UI、Blueprint、Bootstrap、Semantic UI等）这样的系统，你不仅可以获得一套预建的技术组件，还可以获得一个与设计师工具紧密集成的系统。通过将工程师和设计师的工具集成到同一个系统中，你将确保设计师创建的内容与工程师可用的组件完全对应。这减少或甚至消除了工程对自定义样式或前端UI的需求，并且可以轻松将设计精确到像素级。

以上内容由我翻译，如有不准确或更好的表达方式，请您指正。除了在设计和工程之间保持一致性所带来的效率提升外，大多数设计系统组件的实现还会考虑或自动解决其他设计优先事项，例如可访问性（包括屏幕阅读器和色盲人士的颜色对比管理）、符合UI标准，甚至还支持开箱即用的深色模式。

PRD和规范

产品需求文档（PRD），有时也称为产品规格或规范，是产品开发过程的重要组成部分。请注意，产品规格具有不同的目的，是与技术规格不同的文档（参见《技术规划和规范》，第164页）。PRD有许多方法和模板。诸如lennysnewsletter.com之类的资源定期整理了一些最常见和全面的方法。PRD有一个共同的目的，那就是描述问题背景以及证明一个项目或功能的理由。PRD通常包括需要满足目标的需求列表。大多数PRD将功能的实现方式留给技术规范。

类似于技术规范，PRD也是一个活动文档。随着团队对问题的了解更加深入，或者外部环境的变化，这些文档可以和应该发生变化并更新以保持一致。我鼓励您和您的团队将这些文档作为持续更新的真实来源，记录您在产品开发过程中进行的考虑和最终决策。

EPD

EPD是工程产品设计的行业缩写。这暗示了这三个部门在产品开发生命周期中的重要性，并且需要一种健康的合作方式以产生出色的结果。从业务的角度来看，这三个部门共同负责生产客户喜爱的产品，因此，有一个具有一组商业目标的单一人员为这三个部门指定方向是有帮助的。

产品管理与项目管理

产品管理和项目管理是具有明确含义的行业术语。产品经理负责产品的设计和创建，以及产品应满足的关键绩效指标（KPI）。Melissa Perri的《摆脱构建陷阱》是一本深入探讨了出色的产品经理在组织中可以产生的角色和影响力的资源。项目经理负责指导团队的内部组织，管理内部沟通，并遵守路线图和截止日期。

在创业初期，作为首席技术官，您可能需要同时担任这两个角色。在您的招聘计划的早期阶段，您应该计划拥有一位出色的产品经理，他们可以从您身上分担一些责任。有些产品经理擅长项目管理，而其他人则对此不感兴趣，因此不会花时间和精力进行项目管理。可以说，在创业初期，无论哪种方式都可以，因为团队规模较小，项目管理松散的后果是微不足道的。然而，随着公司规模的扩大，正式化项目管理变得更加重要，如果您的产品经理没有承担这个角色，您应该考虑雇佣一个项目经理来补充他们。

我总的建议是，在EPD团队发展到大约20人时，正式委派项目管理。这意味着正式将项目管理的角色分配给自己，由产品经理来负责，或者雇佣一个专门的项目经理。您将希望在项目管理流程的早期参与，确保为项目管理制定的机制支持您所希望建立的文化，并对所有相关方保持同理心。

管理经理和经理培训

有一句行业说法称，公司最终是由中层管理人员来管理的。这意味着，尽管高层管理人员采取了任何战略和流程，但最终对产出的数量和质量产生最大影响的是中层管理人员。中层管理人员招聘员工，设定他们的日常目标，并对质量标准负责。最好的中层管理人员是“迷你高管”，专注于文化建设，建立协作团队，并努力使其发挥最佳水平。因此，作为高层管理人员，您应该在雇佣、管理和培训这些中层管理人员上投入大量精力。

培训经理是一个复杂的话题，值得专门写一本书，它需要时间来掌握这项技能。尽管如此，我可以给您提供的两个最重要的建议是树立自己的榜样，并建立一种持续学习管理的文化。一旦您雇佣或晋升某人担任管理职位，您应明确表达您的期望是他们将投入时间和精力来提升其管理技能。您可以通过将管理培训纳入他们的个人目标和发展计划中，为他们提供提升管理技能的资源，帮助他们解决管理问题，并教授您所知道的一切，让他们更容易做到这一点。

管理培训并不一定要过分繁琐和昂贵。如果预算允许，我强烈建议为您的经理们聘请外部管理教练。每月安排内部经理阅读/评审也可以启动持续发展的正向循环。

财务和预算

作为首席技术官，您的职责之一可能是承担软件工程部门（有时也包括设计和产品部门）当前和未来成本的责任。作为财务预算的负责人，您应了解过去各项支出的实际花费，以及公司整体的预算分配情况。最重要的是，您需要制定一个计划来合理地证明预算的支出。

一般来说，在技术部门中，人员（工资单）和基础设施/软件即服务（SaaS）是两个最大的预算项目。请记住，雇员的实际现金成本不仅仅包括工资，还包括福利和工资税。一个好的经验法则是，雇员的现金成本比他们的工资高出20％；这个百分比被称为负担率。

预算

大多数财务团队使用复杂的会计和预算软件来管理公司的账目。如果没有这样的软件，他们将拥有一份比您作为首席技术官需要的更大更复杂的公司级电子表格。根据我的经验，财务部门通常不愿意让财务以外的人对核心预算系统进行更改，因此，除非他们给您一个起点，否则您需要为部门制定一个财务模型。

鉴于您的部门成本相当可预测，并且集中在几个项目上，您制定的模型并不需要非常复杂。我建议您保持一份包括以下内容的电子表格：

工资单标签
SaaS/销售成本标签
基础设施标签
其他标签（包括旅行、硬件）总结标签

您可以在ctohb.com/templates上找到一个示例的技术部门预算电子表格，它将帮助您实际建模的大部分工作。

与CFO合作

如果您的公司像大多数初创公司一样，您的部门很可能是成本最高的部门，您的首席财务官应该充分了解这一点。以下是一些建议，这些建议对您很有帮助，将使您的首席财务官成为您最好的朋友：

帮助首席财务官了解资金的使用情况和将来使用情况。尽可能避免令人意外的事情。提供关于硬件成本、旅行/会议费用和云成本等方面的指导。
为您的部门制定和及时更新预算，以反映预测的变化。
定期使用财务部门的实际数据更新预算，并确保了解和管理预测和实际之间的差异。
建立一个招聘计划，并包含预估工资。
SaaS账单通常难以追踪。考虑使用信用卡对账单分析工具（例如SaaS管理平台）或雇佣助理定期将这些费用进行分类和核对。
财务部门通常非常关心成本归属以区分；例如，作为成本销售商品的成本。在您的预算中为每个项目粗略地说明原因，可以赢得财务方面的支持。

测量工程速度/健康状况

我尚未遇到过一个能够持续和有用地量化实际工程产出的技术团队或领导者。这包括将速度量化为完成任务估计的总和。（有关技术估算的不可靠性，请参阅《工作流程》第160页的估算部分）。

然而，我确实见过许多公司有效地衡量工程健康状况和对工程速度的影响因素，即周期时间和工作时间分配。

周期时间

周期时间是从构思到发布功能所需的时间的测量，通常细分为以下子里程碑：

编码时间
代码审查开始时间
代码获得批准的时间
部署代码所需的时间

一般而言，周期时间较短的团队更高效，能够进行迭代、创新并更快地为客户提供价值。有许多工具可以促进测量周期时间，包括LinearB（linearb.io）和Code Climate（codeclimate.com）。LinearB已发布了一组基准，使用了成千上万个工程团队的数据，用于与周期时间相关的指标。

工作时间分配

衡量工作时间分配的理念是，尽管很难衡量完成了多少工作，但相对而言很容易衡量团队成员在做什么样的工作上花费了时间。这些信息的结果是有方向性的。例如，如果一个团队花费大部分时间解决bug，那么可以有合理的假设：提高软件质量并减少消耗时间的百分比将导致将更多的时间分配给开发新功能，从而改善整体的健康状况和速度。

实际衡量工作时间分配可以通过从工单系统中提取报告来进行半自动化处理，或者可以使用定期的轻量级脉冲调查向团队进行测量。

筹款和尽职调查

一般而言，作为首席技术官，您在筹款和尽职调查方面的角色相对较小。在大多数初创公司，CEO和可能还有CFO会承担大部分工作。您的参与通常在投资者对公司进行尽职调查时发生。在尽职调查中提出的许多（但不幸的是，并非全部）要求是寻找一个良好组织的工程团队已经作为业务运营的一部分进行了维护的信息。注意以下内容，并准备好就尽职调查提供：

组织结构图
部门预算
所有工程部门创立和维护的产品的全面描述
工程路线图（通常寻找短期/中期路线图）
主要技术债务领域的列表，我称之为技术债务资产负债表（见《技术债务》第145页）
高层次系统架构图
完整描述软件是如何分发和更新的，无论是作为SaaS还是作为版本化的桌面/移动软件
关于系统如何托管和您的安全实践的高级描述
关于软件许可的信息，包括确认公司代码没有违反任何许可证或未经许可的专有软件的代码扫描结果

投资者聘请第三方公司进行技术尽职调查并不罕见。这些调查可能涉及对您和团队其他高级成员的访谈或会议。准备好讨论您的工程流程，评估团队的一般生产力，并对系统的部分代码进行代码演示。

我的建议是对这些审计师坦诚相待。他们看过很多科技公司，并清楚地知道所有工程团队都有技术债务和团队对某些部分更为骄傲。您的投资者越了解您的优点和缺点，他们就越能够支持并追求您的团队改善弱点的责任。

供应商管理

总体而言，作为首席技术官，您将负责寻找、与第三方技术供应商进行谈判和管理。对大多数人来说，这是一项令人不愉快但必要的工作，因此往往没有仔细考虑。然而，良好地履行这一职责可以为企业节约大量成本。在这里，我将逐步介绍典型的SaaS谈判/签约过程，并提供一些增加效率和节约成本的技巧。

自助注册工具

通常情况下，您或您的工程团队的一个成员会提出对某种工具的需求，如果是您的工程师或经理，他们会要求您批准支出或自己为工具注册。许多工具成本不重要，而且有简单的自助注册流程。我建议您与预算和财务团队合作，设定一个阈值，低于该阈值，您的经理被授权独立注册工具。对于超过成本阈值或没有自助注册的工具，您将需要与企业供应商进行发现和谈判，该过程通常包含四个步骤。

企业工具

您现在面临的是企业销售过程。在联系供应商的销售团队之前，确保这家公司是最适合解决您问题的公司。在大多数情况下，我建议您开始制作一份电子表格，对这个领域内的所有供应商进行一些尽职调查，并筛选出两到三家最佳选择。即使其中有一个明显是您首选的选择，也没有坏处对这个领域进行更深入的了解，并获取谈判知识/筹码（最佳替代谈判协议）。

销售资格

当您向企业供应商首次联系时，几乎肯定会进入所谓的销售资格过程。在这个阶段，特别是作为技术主管，您的需求尚未与供应商对齐。您可能正在寻找价格、合同和尽快开始的最短路径。供应商希望确保您是他们的目标客户，并且可能在未来几年内不会流失。

大多数SaaS销售公司都会由前线销售代表接待初次电话，他们的主要目标是了解您的公司，并确定您是否符合他们的客户定位。他们可能没有太多的技术知识，通常无法与您讨论价格。因此，您可能无法从这次初次会议中获得太多价值。我的建议是要么委派这些介绍性会议，要么尝试从销售代表那里获取销售资格问题，并通过电子邮件对它们进行足够回答，从而完全跳过介绍性会议。

谈判

一旦供应商确认您符合其目标客户的要求，他们将安排第二次会议，与他们一方的更高级别资源进行谈判。通常，这将是一个销售经理或者可能是技术销售代表。这是您开始获得有关解决方案的更多技术问题的阶段，您将了解到供应商所授权使用的价格模型的透明度。

以下是一些建议的谈判技巧：

切记，最终一天的事实上，销售员的工作就是向您推销产品，因此在达成互相同意的条件时，您和销售员是同一团队的。您越能透明地表达对您来说重要的事情，他们就越能制定出满足您需求的销售协议。
不要低估除总成本外的其他因素，例如总合同期限（较长的合同应享有较大的折扣），付款频率，付款条件（例如，净 30，净 90），或者在任一公司控制权发生变化时合同的处理方式。
通常来说，寻找与您业务增长相匹配的合同。理想情况下，初始成本较低，随着工具的大量使用和提供更多的价值，成本会随时间增长。鼓励一种“我们共同成长”的心态，有助于降低初始成本。
让您的财务和合规团队了解情况。如果您的首席财务官擅长谈判，让他们负责这个过程的一部分。
如果您的 SaaS 总预算很大，或者您正在谈判很多这样的交易，请考虑使用第三方谈判人，例如 Vendr。通常，这些谈判人将根据他们为您节省的费用收费，并且他们拥有比您更多的合同数据，以了解定价情况。
请注意，月底/季度末的销售配额是真实存在的，这个时间期间的折扣非常普遍。

签约

一旦您就条款达成协议并交换文件，下一步是找出贵公司的授权签字人是谁（假设您是其中之一），将相关文件签署并进行组织管理。

不要丢失或遗失这些合同，它们将对将来的谈判或尽职调查很有用。确保在预算或 SaaS 管理平台（SMP）中跟踪成本。

销售后

在签署交易后，您可能会被移交给供应商的另一位代表，他们的职务类似于售后支持或客户服务经理（CSM）。这些人的激励、衡量和关注点都是客户保留或产品升级。他们对产品有深入了解，并且至少在一定程度上具备技术能力。从现在开始，他们将成为您寻求新功能和解决缺陷的倡导者。

您是哪种类型的CTO？

无论您是CTO、扮演CTO角色的首席执行官，还是希望聘请CTO的创始人，了解CTO在初创公司中的具体职责以及与更成熟公司中的高管和领导职位的差异非常有帮助。和大多数事情一样，答案取决于具体情况，并会随着时间改变。Calvin French-Owen撰写了一篇很棒的文章（ctohb.com/founder2cto），将CTO分为四种原型：人员领导者、架构师、研发、和市场/面向消费者。我喜欢这种划分，并在此基础上进行了一些修改，总结出以下三种类型：

技术导向型
以人为本型
外部导向型

技术导向型CTO（又称首席架构师）

技术导向型CTO可能也是CTO办公室的领导者，领导一个内部技术试验组，主要输出前瞻性战略、架构，以及有时关于如何帮助业务发展的概念验证实施。这个CTO手下的下属较少，工程组织的大部分人员归属于独立的工程副总裁领导。在这种情况下，工程副总裁（VPE）通常会向首席执行官或首席产品官（CPO）直接汇报，而不是向CTO报告。

内部技术导向型CTO还可能是首席技术流程架构师，负责建立技术工作的工具、系统和流程。

作为内部技术导向型CTO，如果贵公司的产品具有高度技术性质（例如开发者工具、API 服务等），您还可能担任产品经理的角色。

以人为本型CTO（又称工程副总裁）

典型的初创公司通常不会同时拥有工程副总裁和CTO，因此通常由CTO兼任工程副总裁的角色。对于创始人兼任CTO的角色来说，这通常也是最难扮演的角色，因为初始技术创始人的职责与内部以人为本的技术领导者的职责不太相同。

以人为本型CTO负责制定内部技术文化、招聘流程和监督内部流程。这个CTO的大部分时间都花在管理自由贡献者或其他技术经理上。这是三种关注领域中最关键的一项，确保做好这方面的工作非常重要。如果公司招聘不善，或者技术人员管理不善、缺乏动力、缺乏重心或者没有对齐，这可能会影响生产力，甚至会导致长期内对组织伤害。

外部导向型CTO（又称技术销售/市场负责人）

这可能是初创公司CTO中最不常见的关注领域，但在正确的时间和地点却同样重要。通常，您会在为技术受众（例如开发者工具等）构建产品的公司中看到这样的CTO。这些CTO会花费大量时间撰写博客文章或在会议上发表演讲。也许他们会被带入销售会议，作为高层技术代表来达成大型交易。请注意，围绕技术团队建立品牌不仅对产品销售有积极影响，而且还可以成为招聘的强大工具，减少招聘的时间和成本。

对于创始人兼任CTO的角色来说，扮演外部导向型CTO可能是最容易的，因为他们对公司的历史背景有深入了解，可以最真实、最热情地讲述公司的故事，宣传其产品和价值。

不同类型之间的转变

理想情况下，初创公司CTO应在这三个领域都表现出色，但大多数人只会专注于一两个领域。如果您的业务需要超出您专业领域的关注点，值得询问自己是否可以将任务委托给一位同事来更有效地执行。尤其在初创阶段，大多数技术创始人/创始人CTO将是内部以技术为导向的。在这个阶段通常不会有太多其他工作要做！

很常见的情况是，随着公司的发展，这个人会把注意力转向内部人事或外部关注领域，但对于这个人来说，并不总是一个理想的职位转变。承认您的专长或动力在技术方面，而人事管理并不适合是不是个人失败，相反，这正是他们的优势所在。发现您的超能力并在公司中设计一个角色来发挥这些超能力，这是您为公司增加最大价值的方式，公司应该聘请其他人，他们的超能力可能是人事管理，并填补这个角色。

如果您发现自己在一个对您不满意的角色中被困住，非常重要的是向自己和首席执行官坦承这种不匹配。这并不意味着放弃您作为创始人或领导者的职位，也不意味着放弃作为受尊敬且具有高影响力的公司成员的职位。

关于不同类型之间的转变，以下是一些建议：

您的超能力：内部技术
- 公司需求
  - 内部人员：聘请以人为本的工程副总裁，积极将CTO的角色定性为技术。
  - 外部关注：如果您还没有比您更擅长的内部人员，那么请聘请一位开发者推广者，并授权他们履行该角色。否则，从内部晋升并确保清楚该角色的职责。
您的超能力：以人为本
- 公司需求
  - 内部技术：如果您的团队中有一位高级工程师或架构师，您可以赋予他们更高的职位，成为技术领导者。否则，技术架构师应该是您招聘优先级的靠前位置。
  - 外部关注：如果您还没有比您更擅长的内部人员，那么请聘请一位开发者推广者，并授权他们履行该角色。否则，从内部晋升并确保清楚该角色的职责。
您的超能力：外部关注
- 公司需求
  - 内部技术：如果您的团队中有一位高级工程师或架构师，您可以赋予他们更高的职位，成为技术领导者。否则，技术架构师应该是您招聘优先级的靠前位置。
  - 内部人员：聘请以人为本的工程副总裁。

在许多情况下，最终结果可能意味着聘请一位CTO，他的超能力与公司当前需要更加匹配。在其他情况下，这可能意味着聘请一位非常出色的以人为本的工程副总裁，以补充一位高度技术的CTO。

本文是 THE STARTUP CTO’S HANDBOOK 中译版，由极客智坊翻译服务自动翻译完成，另有中文PDF版本提供下载：创业公司CTO手册。