将团队时间花在对业务重要的事情上

当面临巨大、模糊的挑战时。

• 采用收集、分析、行动三个过程。
• 吸收尽可能多的信息。阅读可用的文档，无论是 wiki 文章、性能评论、代码，还是你能找到的与你的问题相关的任何内容。安排与相关人员的一对一会议，并详细记录你的发现。
• 当你开始多次看到相同的事物并且不再看到新的模式时，你就知道你已经吸收了足够量的数据。
• 一旦你收集了足够多的与你的问题相关的数据，就不要再收集信息了，给你的大脑一些时间来处理。我建议在此阶段至少分配几天时间。尝试刻意停止接受新信息，并花时间从不同角度看待问题。做笔记、画图表、打高尔夫球、洗澡，或者任何可以帮助你思考问题并提出适合数据且可操作的分析的方法。
• 一旦你有了依据，就该真正制定计划了。当你采取行动时，验证你的计划是否达到了预期的结果非常重要。只要有可能，就进行测试、验证，并在必要时重新启动循环。

做出合适的决策

• 开发与团队一起决策的材料有三种模型。你可以完全自己制定材料和决策，并将结果作为既成事实呈现给团队。还有相反的方法：你从头开始，与部分或全部团队完全共同开发材料。第三种方法是前两种方法之间的折衷方案：自己制定草案，并将其作为稻草人呈现给团队，作为收集反馈和迭代以获得最终版本的起点。优化支持的好处是确保团队中的每个人都理解决策并能够成为这些决策的拥护者，这是确保大家朝着同一个方向前进的唯一方法。正如硅谷产品集团的马蒂·凯根所说，你希望你的团队表现得像传教士，而不是雇佣兵。
• 在 1997 年致股东的年度信中，杰夫·贝佐斯概述了将决策分为 1 类和 2 类决策的框架。贝索斯写道，第一类决策是不可逆转的，应该有条不紊地、仔细地、缓慢地、深思熟虑和协商地进行思考。如果你走进一扇门，但不喜欢另一边看到的东西，你就无法回到原来的地方。例如，你使用哪种编程语言是第 1 类决策。
• 类型 2 决策则相反。它们可以而且应该由具有高判断力的个人或小团体快速制定。按钮的确切灰色阴影可以是第 2 类决定，因为它很容易更改。
• 大多数日常技术决策都是类型 2，最好在通过原型或 MVP 实现收集更多数据后快速做出并重新审视或确认。这是因为大多数初创公司技术决策中最昂贵的因素是工程团队在解决方案上投入的时间。如果你故意限制验证可逆决策所投入的时间（以及成本），那么你只会损失一点点。大多数第 2 类技术决策只有在你投入大量时间和新工程之后才变得不可逆转，因此请尽早严格评估进度。当有疑问时，请尽早做出撤销的决定。
• 弄清楚什么对你有用；也许是冥想、高尔夫、电子游戏或家庭时光。做任何感觉良好的事情，让你精神焕发，为下一个挑战做好准备。
• 对不确定问题的记录和整理，通过管理方式来解决问题。基本上都做不到改变人。确定成工作方式，有些问题是一对一去解释，通过某种管理去让他适应和获得自己的反馈；有些问题是有争论，把所有争论的点都写下来，做出一个决定，这个决定的风险是知道的，什么时候复盘和复盘的标准是什么，哪些东西估算对了，哪些东西估算错了。

招聘对的人

• 决定聘用的第一步是确定团队中的差距。差距有多种形式。通常，在公司发展的早期阶段，这只是技能差距。例如，你的企业决定移动应用程序将成为你进入市场策略的关键要素，而你的创始团队以前从未在移动领域工作过。当然，随着时间的推移，他们可以学习并变得高效，但从短期和长期来看，聘请一位有移动工作经验并愿意在移动领域工作的高级工程师来构建和维护该项目会更加高效。
• 其它类型的差距包括资历差距（没有足够的高级经验来做出正确的决策，或者没有足够的初级人才来处理不太复杂的任务）、管理差距（一名经理负责太多的人）或主题专业知识差距（没有人负责）对行业某个领域有足够了解以指导决策的团队）。
• 雇用的另一个主要理由是增加团队的总带宽。此类招聘应与某种业务目标或产品路线图保持一致，以证明在特定时间引入新的永久团队成员是合理的。
• 尽管并非总是如此，答案就是现在！你雇用的每一位新员工都会增加团队的复杂性和开销。假设差距并不严重，如果你可以再用一个较小的团队六个月并推迟招聘，这可能是一个好主意，因为它既可以降低成本，又可以让你有更多时间来构建案例为了雇用。
• 你必须清楚地了解你的部门对该公司的模型的贡献，这主要以人员费用（当前和未来）的形式出现。该模型应该以年度预算或费用运行率的形式提供一定程度的约束。
• 有些人的级别可能不正确，有些人不适合文化，还有一些人会在第一年被解雇或退出。需要有指标进行观测。
• 传统的职位描述简要描述了该职位的职责，然后是对候选人的要求的项目符号列表。我鼓励你写更多。不要关注成功的候选人在特定职位上会做什么，而是要仔细思考该职位所服务的目的。该角色会带来什么结果？你期望这个角色在三、六个月或十二个月内产生什么样的影响？
• 面试过程包括候选人/简历接收表格、电话筛选、文化面试、技术面试、编码作业或采取-家庭作业、高管面试，最后是背景调查。

编程面试

• 编码面试或作业有多种风格。作业范围从带有提示的带回家项目，到使用在线平台进行编程练习（有时也称为代码套路），再到现场结对编程。由于缺乏有关这些风格的预测能力的任何经验数据，我鼓励你设计一个尽可能类似于公司日常工作的练习。如果你的公司没有进行任何结对编程，那么直观地衡量候选人在结对编程面试中的表现并不会让人感觉高度相关/可预测。至少它正在收集切向信号。
• 尽可能灵活地选择语言/工具。
• 允许异步完成工作（即带回家而不是实时编码）。
• 尊重候选人的时间，我建议为带回家的工作提供严格的时间限制。时间限制的目的不是提供时间压力并迫使候选人快节奏地交付，而是确保候选人不会在挑战中过度投入并认为挑战是合理的要求。为了确保候选人了解时间限制，应该做出解释：
• 对时间限制提供充分的解释。
• 确保任务可以在规定的时间内轻松完成。
• 让候选人知道他们提交的材料将如何被评估。如果你的评分标准对候选人的自述文件进行评分，那么让候选人知道他们应该花时间编写自述文件。如果代码将与候选人一起实时运行或由面试官异步运行，请让他们知道运行时间将被判断。如果你主要关心架构决策而不太关心运行时性能，请也让他们知道这一点，以便他们可以以正确的方式花费时间。
• 许多最大的科技公司都采用经典的技术面试，其中涉及某种形式的共享白板体验，要求候选人实时解决技术问题。问题范围广泛，从学术性的、对具有某些特殊条件的数组进行排序，到高级/手波式架构，设计一个系统来处理 1 亿用户发布新闻提要更新。

面试范围

• 要了解候选人的优势和劣势，以及这些优势对你所招聘的职位有多重要，首先你需要确定哪些主题领域对你的职位很重要。你可以通过创建技术焦点面试指南来做到这一点，该指南应包括四到八个技术领域的列表，并在每个领域内提供一组示例问题、最佳实践答案和评分指南。
• 包含样本答案和评分指南，以确保多个面试官和候选人之间评分的公平性和统一性。你试图区分任何给定的候选人与真正的专业知识之间的差距，因此你的问题应该设计成引出三种答案之一：不好、好和令人惊奇。因此，它们应该适合被这样评分。在对问题进行评分时，为了使知识差距和真正的专业知识之间的差异显而易见，我建议错误的答案得分为 0-2，好的答案得分为 3-6，只有出色的答案才能得分答案在 7-10 之间。
• 当我说一个糟糕的答案时，我的意思是对问题的回答表明对当前主题几乎没有经验或专业知识。一个好的答案表明了该主题的能力，甚至可能是非常高水平的能力。一个令人惊叹的答案不仅展示了能力，而且展示了对该主题的真正理解和知识深度。例如，如果问题涉及候选人如何考虑设计单元测试套件，而他们的答案是他们从未考虑过，那么这是 0，你就发现了差距。如果他们的答案包括对他们设计的一些测试套件的描述以及一些理由，那就很好，也许是 5 或 6。如果他们的答案包括测试套件设计理念的完整概述以及每个测试套件的优缺点以及如何将它们应用到不同的场景中，现在你看到的是真正的专业知识和 7-10 分。
• 初级工程师应该具有好奇心、渴望学习，并具有扎实的编程基础，可以从事增量功能开发。相比之下，高级员工不仅应该具备编程基础知识，还应该对各种工具和问题的架构、观点和最佳实践进行深入思考，并且能够建立信任，相信他们不仅可以构建增量功能，还可以拥有自己的能力。

什么样的人是优秀的？（YC 的 《怎样创立一家创业公司》）

• 聪明
• 有行动力
• 相信自己的直觉，判断是够愿意与之一起共事
• 有良好的沟通能力，一方面能清楚表达自己的想法，另一方面能倾听他人的意见。
• 愿意承担风险。其实愿意选择创业公司本身就是愿意承担风险的表现，但创业是最近比较时髦的话题，难免有盲目从众者混入其中，所以还是要确保对方的确有承担风险的心理准备。
• 有狼性。努力在自己的领域内做到最好，没有什么能够阻挡。
• 团队招人上的时候也要不单单考虑到性格上，什么样的人对现在的组织流程特别有效。能够很好的吸纳对应的背景的人。

尽可能使用可靠的工具，并在重要的地方进行创新

• 这几年慢慢学会的一件事：工具和决策没有绝对的对与错，只有在当前全球市场环境、自己的团队技能栈下是否适合。不同级别的工程师需要花多少时间的能得到多少回报。

自动化释放速度

• 作为团队架构师，你的目标是确保你的团队将尽可能多的时间花在为业务创造价值的代码上。开发人员定期执行许多耗时的任务，这些任务对于编写代码来说是必要的，但它们本身并没有增加业务价值（例如，复制生产环境、让代码在本地运行、弄清楚如何运行测试套件、在云中配置功能分支环境，跟踪测试未涵盖的错误等）。

频率降低难度

• 在“频率降低难度”的标题下，马丁·福勒 (Martin Fowler) 阐述了“如果疼痛，就更频繁地做”这句话。福勒认为，任何对你的团队来说痛苦、容易出错或成本高昂的流程或任务，都是该任务开发不足的症状。如果没有你的压力，痛苦的技术任务往往是最后自愿承担的。结果，他们被忽视了，而且随着时间的推移，疼痛会变得更严重。或者，如果你的团队文化强调优先考虑这些痛苦的任务，那么就会付出更多的努力来自动化、记录和改进这些任务，最终使它们不那么痛苦，甚至完全自动化。正如福勒指出的那样，更频繁地执行任务还可以提供更多反馈，并通过练习培养技能，所有这些都进一步减少了任务的难度和痛苦。

标准化 RFC 流程

• RFC（或请求评论）是概述技术思想、流程或规范的文档，其编写目的是为了同行评审和后续采用。你熟悉的大多数协议都有关联的 RFC，例如用于 HTTP 的 RFC 2616 或用于 DNS 的 RFC 1035。同行评审以及随后的采用和标准化的想法是一个强大的工具，可以伪民主地制定技术决策并获得结果的支持，并且它可以成为与你的团队一起使用的绝佳工具。

将速度作为目标，而不是策略

• 在《好战略/坏战略》一书中，作者理查德·鲁梅尔特 (Richard Rumelt) 将好战略定义为提供三个要素的战略：对如何克服挑战的诊断、指导性政策或总体方法，以及制定政策的一系列行动。执行。战略概述了旅程。

参加继续教育和技术会议

• 我鼓励你要求与会者制作一份书面文件，总结他们回来后学到的关键知识。你还应该考虑赞助与你的业务最相关的会议，并让你或你的团队成员之一就特定主题举办研讨会。这些研讨会和赞助为你的公司提供了绝佳的品牌机会，将你的名字和信息展示在非常有针对性的受众面前，这些受众可能包含你将来想要雇用的候选人。

部署橡皮鸭调试

• 橡皮鸭调试是通过首先大声说出问题来解决问题的过程，也许是对着桌子上的真实的橡皮鸭。这个想法是，通过大声说出问题，人们通常会听到缺陷，或者看到问题的解决方案，而这些问题是他们在头脑中出现时没有考虑到的。橡皮鸭方法可能会避免同事的打扰，并让你更快地得到答案。

建立一个讲解视频库

• 如果一张图片相当于一千个单词，那么一段一分钟的桌面/IDE/应用程序视频（其中包含你讨论技术主题的声音）就可以为开发人员节省 1,000 美元的时间。有许多工具可以轻松录制和分享这些迷你视频消息，包括 Slack 和 Loom 中内置的工具。通过屏幕录制和画外音，你不仅可以比文本更轻松地清晰地传达技术想法，而且可以在自己的时间里完成。观看者可以自行决定对生成的视频进行加速，并且可以将视频存档并作为组织知识库的一部分稍后重新观看。

管理是每个人的责任

• 你的团队不断创造知识，无论是如何启动服务，还是如何在代码库中使用代码模式。有两种方法可以解决这个问题：你可以什么都不做，每天都会增加新员工的知识差距，或者你可以积极地将孤立的部落知识转换为当前和未来的可扩展文档雇员。出于显而易见的原因，我推荐后者。这意味着每个人都应该经常问自己，我如何记录我刚刚创建/学习/发现的内容？当你的新员工遇到在你的知识库中找不到的东西时，他们就需要寻找答案并将其记录下来。

参考资料：

• 《Startup CTO Handbook》
• YC 《怎样创立一家创业公司》
• 一些行业更资深的技术管理者的访谈