你是如何陷入瓶颈的？
一个不断发展的初创公司通常会低估其入职流程的重要性。快速扩大员工规模的需求可能出乎意料地出现。某个事件可能会触发团队规模的扩大——也许产品在客户中获得了成功，或者初创公司收购了一家公司，或者转向了新的产品方向。很快，计划就变成了初创公司现在需要多少人才能实现其新目标，招聘团队开始面试并发出录用通知。在压力增加的情况下，你没有时间优化入职流程。如果之前没有建立有效的入职系统，新员工就会被分配到团队中，被分配一些任务，然后让他们自己想办法变得高效。如果团队成员没有协作帮助新员工快速上手，没有入职文档，代码难以阅读，或者产品目标和 KPI 不明确，那么问题就尤其严重。然后，新员工可能会迷失方向，感到不满，效率低下。在本文中，我们将探讨公司因入职流程效率低下而陷入瓶颈的迹象，以及我们在 Thoughtworks 加速工作室中看到行之有效的最佳实践解决方案。
除了为新员工入职，该流程还用于重组团队。工作室认为，快速学习、快速失败和重新聚焦的能力是成功扩展的重要技能。一个灵活的初创公司会根据学习和环境变化进行调整，这涉及改变产品团队目标，并重新分配资源以最佳地实现新目标。为了轻松做到这一点，我们需要让重新分配的团队成员能够快速上手。本文中的大多数功能也适用于重组。
入职是关键的业务流程
入职通常被认为仅仅是授予访问权限，并在将新员工交给他们的经理和团队之前完成一些行政任务。它不被认为是一个端到端的业务流程。但是，一个运行良好的入职流程会解决社会和文化融合问题，并促进新员工需要与之互动的不同职能之间的协作。入职流程通常涉及人力资源、工程管理、法律、IT 运营、安全和产品团队成员。跨越如此多的团队意味着它可能非常零散。优化流程很困难，因为通常没有人拥有整个流程，你必须将所有不同的参与者聚集在一起。
软件领导者在制定招聘计划和支持招聘工作方面付出了很多努力，但往往忽略了如何让新员工变得高效。我们认为这是一个错误，因为有效的入职会对新员工产生“倍增效应”。
从临床角度来看，新员工的价值是什么？如果没有适当的入职，新员工只会展现出其价值和生产力的很小一部分，有些甚至低至 50%。如果投资回报率处于这个水平，你不太可能实现预期目标。领导者被迫进行额外的招聘，这将增加组织的复杂性和管理人员的工作量。为了避免这种情况，我们建议在优化入职方面投入与招聘新员工相同的精力。
我们认为，入职流程不会在一周或一个月后结束——它会持续到这个人完全高效为止。一旦有人接受了录用通知，入职流程就开始了，然后是强有力的新员工入职培训，接收笔记本电脑以及访问相应的系统。它在他们加入团队后继续进行，因为他们第一次执行职责，与团队成员和经理建立关系，并培养围绕其常见任务的习惯。入职的最后阶段使员工能够达到完全高效，他们可以创造性地为团队做出贡献，教导他人，并回馈入职流程。这个时间线取决于角色、领域和复杂性。
最佳入职时间线
为了衡量你的进展，此表代表了我们观察到的开发人员入职的最佳时间线。我们将在本文的其余部分进一步解释这里提到的概念。
| 里程碑 | 完成时间 |
|---|
| 访问所有 HR 和行政系统 | 第一天 |
| 访问工作站和个人开发环境，并使用必要的工具进行设置 | 第一天 |
| 解释和讨论公司使命和业务目标 | 第二天 |
| 在同伴的帮助下，完成对微不足道更改的生产推送 | 第三天 |
| 经理与员工设定了期望，并为他们提供了 OKR | 第一周 |
| 与同事结对开发一个真正的功能，一直到生产，并执行缺陷解决 | 第二周 |
| 了解关键的客户问题和内部运营流程 | 第二周 |
| 开发人员：能够成为故事的“锚点” | 第 3-5 周† |
| 开发人员：能够领导支持电话 | 第 5-7 周† |
† 取决于复杂性和经验
你正在接近规模瓶颈的迹象
新开发人员无法进行生产部署
一个可量化的指标是新员工编写代码、提交代码并部署到生产环境所需的时间。这应该在第一周内完成——理想情况下是在前几天完成。它不必是一个复杂的任务，可以是一些非常微不足道的事情。这个指标表明开发人员的计算机和开发环境设置正确，并且拥有独立推送到生产环境所需的一切。我们发现，有些情况下，新开发人员在公司工作了数周甚至数月，但还没有将任何内容部署到生产环境中。
新人感到被遗忘
尤其是在初创公司，大多数经理都专注于新的计划，他们手头的工作比他们能处理的还要多。很容易将整合和帮助直接下属快速上手的工作降级。新员工被留下来自己想办法；学习系统、建立关系以及如何获取他们需要的资源。更糟糕的是，如果他们没有得到明确的目标，他们最终可能会做错事。员工变成了孤儿，导致生产力大幅下降或快速离职。这种文化问题很难发现。我们建议倾听你的经理和新员工的反馈。离职面谈也是宝贵的数据。
过分关注个人工作
当初创公司通过增加新员工来扩展规模时，这可能会触发不同的运营模式。这是一个小型团队，构建了最初的产品和技术平台。每位工程师都专注于构建和支持应用程序的一部分，很可能是他们自己完成的。随着扩展到更大的团队，我们经常观察到一个问题是，资深员工没有花足够的时间来帮助新员工入职——与新工程师合作和结对，记录他们的工作方式，并解释技术决策的原因等。这使得入职变得非常困难。
随着团队规模的扩大，目标不仅应该关注个人贡献，还应该包括整个产品团队的绩效。在回顾产品团队时，理想情况下应该寻找机会帮助新员工提高生产力。我们看到的一种反模式是，将个人分配到各自的工作流中进行计划，因为这消除了知识转移的机会。
对改变不够开放
当你招聘新员工时，他们可能与现有团队拥有不同的经验（特别是如果你是在个人网络之外招聘的）。他们会有不同的观点和看法。我们经常看到公司没有利用这一点。一个典型的情况是，初创公司可能有一支“老手”团队，他们已经找到了一种工作方式，有自己的怪癖，并且每个决策都有其历史。团队在方法上固执己见，并否决了新人的新想法。这会让新员工感到没有权力，不被重视。
同样，这也是文化问题，很难发现，但有一些反模式需要注意
- 现有员工霸占会议，说话很快，或者没有给新员工足够的时间来贡献或澄清。
- 过度保护现状；否决想法——“我们试过这个了”，“它在这里永远不可能奏效……”。
- 通过非正式渠道进行私下沟通；资深员工可能通过他们已建立的网络来完成工作，为他们提供“帮助”，而不是通过记录的流程。
快速离职
新员工的离职率是一个滞后指标。高离职率可能有很多原因，但值得调查。它可能与您的入职流程有关。可能是您的新员工没有得到适当的培训和公司欢迎。您的团队应该监控离职率及其趋势，并在新员工入职 6 个月和 1 年后进行调查。然后，您可以利用这些经验教训不断改进入职流程。
文档无法回答新员工的问题
新员工，尤其是横向招聘的员工，通常在较高层面上了解需要做什么。但是，新环境的特殊情况可能会妨碍他们完成即使是日常任务。例如，不知道源代码库的位置或集成测试环境的基准 URL。结构良好的入职文档可以帮助提高生产力，增强信心，并总体上提供愉快的体验。为了不断改进并保持文档的最新状态，应鼓励新员工查找文档中的错误并修复它们。
如何摆脱瓶颈？
当您考虑设计入职流程时，全面考虑员工效能是一个好的第一步。在接下来的解决方案部分，我们将描述如何创建通往效能的路径，一个在 Checkr 应用的入职优化示例，以及我们认为重要的技术。
创建一条通往有效性的道路
在 最大化开发人员效能 中，Tim 谈到了专注于结果而不是产出的理念，以及如何让员工参与进来，为您的企业和客户创造最大的价值。赋能的员工不仅仅是根据需求编写代码，根据规格设计，或根据销售团队的要求创建功能。他们会创造性地思考问题空间，提出成本效益高、可扩展且创新的解决方案。让我们看看赋能的员工需要什么，以及入职如何实现它。
对公司使命和业务目标的清晰认识
领导者应该为使命创造兴奋感，概述使命的起源、未来的可能性以及员工如何为之做出贡献。这应该包括对当前产品策略的了解。
公司如何赚钱（或打算如何赚钱）？
为了灌输商业意识和节俭意识，新员工应该了解公司目前如何收费，其盈利能力以及其投资水平。
对客户体验的同理心
让所有员工都期望思考客户。我们可以通过多种活动来强调这一点——观察客户使用系统，以客户身份使用系统（如果可能），以及阅读有关客户问题的先前研究。
对内部运营的了解
大多数软件系统都有不同的用户（除了目标客户之外）。了解所有这些方面很重要，这样技术人员就可以设计出使这些内部用户高效的解决方案。这在规模化时尤其重要。
业务领域理解
许多业务领域非常复杂。理解需要时间，但我们可以从专家的概述和建议的阅读材料开始。
与团队的合作关系
为了能够公开讨论新员工的担忧和想法，他们需要与同事和经理之间建立一定程度的熟悉度和脆弱性。入职应该包括促进这种关系的活动。远程工作更难做到，因此我们建议团队在新员工加入后的头几个月内进行面对面的聚会。
对目标的清晰理解
赋能的员工需要目标，他们需要知道公司希望他们实现什么，以及如何根据目标进行评估。
当前团队拓扑结构
新员工应该清楚地了解产品和系统的归属权，以及他们可以向谁咨询信息。一个最新的组织结构图，以及他们在其中的位置至关重要。有意地在最初几周安排一些一对一会议，是鼓励跨团队和职能沟通的好方法。
如何利用技术
每家初创公司都使用技术来创新和扩展，因此所有员工都应该具备一定程度的理解。我们认为将角色划分为“技术”和“非技术”是无效的；有些角色只是比其他角色“更技术”而已。
将会有特定于角色的需求。开发人员需要了解如何
编写代码并推送到生产环境
一个完全设置并正常工作的环境，可以访问部署，他们能够独立地完成它。该环境让他们相信它会发现质量问题，并允许他们安全地回滚。
调试和修复生产问题
访问跨系统的清晰可观察性。这应该包括文档、运行手册和典型任务的演练视频。
理解现有的代码、架构和依赖关系
有效的知识管理系统，访问所有源代码库，访问相关团队，以及与队友和 SME 的知识转移。
衡量解决方案的进展
业务和产品分析，以及技术指标（性能、可用性、成本、质量指标）。它应该包括能够对解决方案进行实验（原型、A/B 测试）以及访问定性反馈。
虽然这篇文章主要针对开发人员，但我们可以将这些概念扩展到其他角色。产品经理可能需要
与客户的第一手经验
从介绍关键客户开始。此外，产品经理需要空间来建立关系；我们有时会发现创始人想要成为沟通渠道，这可能会使他们难以获得未经过滤的信息。
阐明当前的产品策略
新的产品经理应该能够快速了解当前的策略、相关信号、当前的产品押注以及它们是否成功。
查找和访问分析
理想情况下，这是自助式和探索式的，而不是必须请求报告。这包括产品、行为、财务、营销和销售指标，以及系统性能指标。
从之前的押注和拐点中学习
产品目前以特定方式设计，原因有很多（可能并不明显）。为了成功地发展产品，了解它之所以如此的原因会有所帮助。
构建实验原型并在系统中“玩耍”
通常，产品经理没有使用演示环境或创建原型的必要权限或资源。
设计师可能需要了解如何
访问工具以创建低保真和高保真资产
除了完善的产品之外，设计师还应该能够轻松地创建可点击的原型，并能够在没有太多仪式的情况下进行用户测试。
查找和使用品牌指南和设计系统
为了确保一致性并使设计和实施 UI 更容易，这些指南应该易于访问且有良好的文档记录。这些系统的成熟度将取决于初创公司的成熟度，从共享设计文件演变为动态组件库。
发现之前的用户研究
之前的用户测试记录、访谈文档和综合研究成果应该可以访问并存储在公司知识库中，而不是个人孤岛中。
执行 A/B 测试并访问行为分析
用户界面应该被检测，以便设计师能够以自助方式获得尽可能多的见解。许多 A/B 测试框架允许独立发布和分析，而无需开发人员支持某些类型的更改。
此列表只是一个示例，并非旨在涵盖所有内容；我们建议您查看您公司角色的目标和“工作要做”。
为了说明这在现实中是如何运作的，我们将使用 Checkr 的例子。
案例研究：Checkr
Checkr 是一家人力资源技术公司，为未来的工作提供动力，与 Thoughtworks 合作在 2018 年至 2020 年间进行扩展。在处理他们的架构、质量和平台工程时，Thoughtworks 顾问注意到了 Checkr 入职流程的有效性。当 Checkr 的规模超出最初的团队时，他们投资创建了针对所有员工的结构化入职流程。该流程旨在培养对客户的同理心，了解业务，并尽快提高员工的生产力。Checkr 领导层认为这是一个关键的能力，他们的入职流程使他们能够将工程人员从 30 人增加到 300 人。尽管取得了成功，但 Checkr 仍在不断发展该流程，因为他们收集反馈并尝试新想法。
跨职能入职周，了解使命，培养同理心
每个月，Checkr 都会为所有新员工举办为期一周的入职“训练营”。训练营的目标是让员工通过听取领导层和 Checkr 跨团队的成员的意见，对公司和产品有一个全面的了解。来自客户成功、财务、产品和工程等其他职能部门的成员将与新员工一起审查团队流程和产品用例。
除了跨职能概述之外，新员工还获得了更多机会培养对客户的同理心，并了解 Checkr 试图解决的问题空间。新员工会去当地法院提取记录，作为客户背景调查的一部分，并参加客户支持电话，作为客户成功代表使用 Checkr 的工具。
最初，学员人数约为 20 人，但随着时间的推移而增长。训练营的另一个好处是，新员工很快建立了内部网络。Checkr 的工程总监 Krista Moroder 说：“我仍然使用我最初建立的网络——我入职时的伙伴之一仍然是我在法律部门的首批联系人之一。”
在训练营之后，他们进行了为期两天的特定角色研讨会，然后是他们各自团队的入职。
开发人员的生产力路径
员工从第一天起就可以访问他们需要的所有服务和工具。工程师可以在几个小时内使用脚本设置他们的个人开发环境。Checkr 的目标是让新员工在第一天就能部署，但实际上这会因团队而异，平均来说是在第一周内。他们目前正在从基于笔记本电脑的开发环境转向基于云的方法，目的是加快入职速度，因为增加了容量和更轻松的配置管理。
许多团队会使用结对编程，这意味着新员工可以直接参与到任何正在进行的任务的结对编程中。Krista 谈到了结对编程
“Thoughtworks 是我最初领导的团队进行结对编程的催化剂。主要动机是减少质量缺陷，减少上下文切换，增加共享知识，提高循环时间，以及在疫情期间完全远程工作时保持人们的联系和参与。团队使用一种模型，工程师在每日站立会议结束后选择当天的结对伙伴。”
在 Checkr，他们使用“你构建你运行它”的方法，每个开发人员都应该支持他们团队拥有的系统。为了学习如何做到这一点，在新员工加入 1-2 个月后，他们会从与同事共同驾驶值班支持开始。他们通常可以在 2 个月内独立解决内部产品的故障，或者 3-6 个月内解决消费产品的故障，具体取决于资历。对于 Krista 来说，“生产力指标是他们的经理或资深开发人员信任新开发人员能够端到端地解决复杂问题。”
质量奖和学习周
入职部分是关于有人加入时发生的活动，但也关于创造一种文化，引导人们走向效能。Checkr 希望鼓励持续学习的文化，公司每年举办 2-3 次由参与者主导的“学习周”，每次都旨在专注于不同的能力，例如基础设施或质量，持续一周。在训练营之前会进行调查，以了解当前的知识差距。这些周提供了一个向同行学习的机会。在理想情况下，每个人都会不断地分享专业知识。但在忙碌的初创公司中，这并不总是会发生。学习周设定了意图，并帮助人们习惯于寻求帮助和分享知识。
Checkr 定期全体会议的重要组成部分是质量奖，员工由同事提名并因其贡献而获得认可。与仅仅庆祝产品发布等典型里程碑不同，人们因在文档、测试、弃用和重构方面的卓越表现而获得认可。这强调了围绕高技术质量和同行支持建立兴奋文化的理念。
除了最初的入职期外，团队还会定期发送调查以评估整个流程。这有助于他们监控流程是否有效，并为公司成功奠定基础。
将新员工纳入公司文化
将新人引入初创公司带来了思想和理念多元化的机会。新员工的经验和知识将使我们的产品更出色，技术更具创新性，流程更高效。为了真正利用这些新员工，现有的团队需要付出努力来正确地整合他们。如果没有合适的环境，新员工很难融入现有团队并做出贡献。现有团队的社会资本和声望令人望而生畏。如果我们能鼓励新员工发声，他们就能大胆地提出新想法，而不必担心被否决。
创建这种安全和脆弱的空间很困难。从第一天开始，从新员工入职培训开始，新员工应该感觉自己属于公司使命的一部分，并能为公司的发展做出贡献。领导者可以从自身做起，以身作则，在互动中树立公司原则。这将归结为个人互动。我们建议培养一种对他人的关怀文化，了解他人的行为和感受，尤其是在入职期。
完善录用后和第一天体验
俗话说，你永远没有第二次机会来给人留下第一印象，这当然也适用于入职。入职从第一次面试开始。面试官与候选人的互动方式将为他们如何看待公司文化以及他们应该如何表现设定先例。从那时起，第一天、第一周、第一个月以及之后的所有经历都很重要，并将极大地影响他们是否会成功并感到快乐。
因此，在入职第一天之前的这段时间至关重要。一旦候选人接受了录用通知，请确保为新员工提供一个明确的联络点（最好是电子邮件组，而不是个人），以便他们寻求澄清。
员工所需的所有工具都应该通过自助服务提供，并在第一天即可访问。没有人愿意在最初的几周内玩“打地鼠”游戏，为他们需要的权限创建工单——这包括拥有自动为员工注册福利、绩效跟踪、工资单和知识库的 IT 系统。
入职清单可以作为指导员工度过第一天的一种有用方式。例如，在 Thoughtworks，新员工会收到自己的 Trello 板，上面列出了入职任务。所有任务都包含分步说明和进一步帮助的联系信息，并按应完成的顺序进行优先排序。这为新员工提供了一个简便的参考，让他们可以完成设置工资账户直接存款等基本任务，以及设置工作笔记本电脑等更复杂的任务。此外，它还允许他们自行跟踪他们在常见任务方面的进展情况以及如何寻求帮助。
新员工会分配一个入职伙伴来帮助他们完成入职流程。为了使这一流程更加无缝衔接，我们有一个“第一年体验”聊天群，新员工和经验丰富的员工都可以在其中提出问题并获得帮助。即使是工作多年的员工，在加入公司几个月后也经常继续使用这个聊天群，它被认为是整个入职流程中最受欢迎的方面之一。
投资于自助式知识管理
令人惊讶的是，专有知识可以迅速积累。一些想法或方法可能在早期的会议中已经很清楚，但从未记录下来。如果我们不花时间记录这些内容，可能会让新员工在最初的几个月感到沮丧。我们遵循敏捷原则“可工作的软件胜过全面文档”；软件代码应该是可读的，但仍然需要一些有针对性的文档。最佳实践包括
- 围绕库、API、依赖项和集成的最新简洁的技术文档——对技术所有者的反馈循环极大地提高了文档的实用性和新鲜度。
- 文档分类和集中搜索，以最大程度地减少查找信息所需的时间
- 共享原则和实践：了解团队通常的运作方式有助于新员工适应新的文化。
- 历史技术和产品决策的记录，可以提供更多关于思维过程背后的背景信息。
- 服务降级后事件的记录。所有问题都是学习的机会，记录问题和缓解措施有助于避免将来出现类似问题。
Thoughtworks 的合理默认值
多年来，Thoughtworks 积累了一套实践、模式、指南和一般性良好建议，这些都使我们取得了成功。本地化设计决策和自主权是 Thoughtworks 文化的关键，但我们希望为横向员工提供一条“铺好的道路”作为起点。这包括针对开发人员、架构师、业务分析师、产品经理、项目经理和执行利益相关者等各种职能的默认值。这些职能还分别拥有各自的聊天、电子邮件组和社区，任何人都可以在其中提出问题、征求反馈、分享想法并挑战现状。
开发合理默认值包括围绕一些关键实践的文档。一些示例包括
频繁且持续的集成
测试驱动开发 (TDD)
结对开发
构建安全
快速且经过验证的自动化构建
自动化部署管道
尽早且持续的部署
有效管理质量和债务
为生产而构建
快速反馈
快速反馈意味着能够在几分钟而不是几天内找出更改是否成功。可能是单元测试已通过，或者我们没有破坏生产环境，或者客户对我们构建的内容感到满意。
可重复性
可重复性是通过消除引入奇怪不一致的手动任务而获得的信心和可预测性。我们还希望将时间花在比解决本应正常工作的问题更重要的活动上
简单性
我们希望软件只包含完成工作所需的复杂性。我们为现在的需求而构建，而不是为我们认为可能出现的需求而构建。但我们做出的选择使我们的软件能够快速更改以满足即将出现的需求。
↑ 部署频率
↓ MTTR
↓ 更改的提前期
↓ 更改失败率
结对编程作为一项关键的入职技术
Thoughtworks 团队经常因我们能够快速上手现有代码并快速学习业务领域而受到客户利益相关者的赞扬。这背后的（并不那么）秘密是 结对编程，Thoughtworks 遵循 极限编程 技术，并根据客户环境进行调整，结对编程是一项关键技术。当我们为团队招募新成员时，他们会花时间与产品经理一起了解产品目标和业务背景。然后，他们会立即开始与团队现有成员结对编程，构建真实的功能。为了学习代码库的其他领域，他们会在不同的故事中轮流与团队的不同成员结对编程。
从我们的初创项目经验来看，我们发现入职期间的结对编程可以加速知识转移并引入学习文化。其他优势包括它创建了关于代码风格和质量的团队规范，在团队成员之间建立信任和脆弱性，并创建了集体代码所有权。虽然你可以通过其他方式实现这些目标，但我们认为结对编程是最快、最有效的方式。这些技术也可以应用于其他学科，例如设计、产品策略和管理方面的结对。
个人环境设置
仅仅给开发人员一套安装说明来设置环境并让他们自己弄清楚是不够的。理想情况下，个人环境应该包含开发人员部署到生产环境并进行调试所需的一切。它应该预先安装或通过几个操作安装。第一周是经理或队友结对执行第一次部署的好时机。通过这种方式结对意味着他们可以建立关系，并且可以看到新员工遇到的摩擦。一个好的做法是执行一个微不足道的任务，以证明环境和部署管道是有效的。例如，Etsy 使用将你的照片部署到他们的团队页面作为入职任务。
根据你的环境，它可以与公司范围的镜像或脚本一起创建，并针对你的团队和部门进行一些定制。通常，最有效的方式是开发人员拥有一个功能上等同于生产环境的副本，其中包含合成数据或混淆数据。随着团队的壮大，环境可能会变得过于复杂和昂贵，无法为每个开发人员提供一个副本；此时，个人环境应该基于团队工作的业务领域的服務和 UI。
个人环境的位置可能是用户的笔记本电脑或云环境。该决定基于许多因素——开发速度是最重要的，但环境差异、隐私和合规性也是其他因素。我们的团队发现，如果你使用了很多云服务（例如，函数即服务），那么最好在云中使用真实服务运行你的个人环境，而不是在本地使用开发版本或存根。这是一个团队必须决定的权衡。将所有内容都从个人笔记本电脑中移开也有助于数据安全。
消除入职流程中的阻力
入职流程中的摩擦是指员工必须做的一切不必要的事情，或任何不必要地缓慢或官僚化的流程。一个团队无法完全拥有入职——它不是一个单一的流程。入职需要人力资源、招聘、IT、学习和发展、领导层、招聘和团队同事之间的紧密合作和认同。组织中许多具有特定职责的人员需要在流程中发挥作用。
我们发现细节很重要——你可以包含一些内容，例如他们在第一周结束时收到的自动调查，或者在学习管理系统中自动分配强制性培训的脚本。你自动化得越多，你就能越保证新员工体验的样子。但是，并非所有事情都可以自动化，并且需要有一个明确定义的流程，让每个人都知道他们在流程中的作用。
持续改进流程
入职是一项跨职能活动，涉及许多利益相关者。通常，需要在这些职能之间进行集中协调，以创建统一的信息和一致的体验。在 Thoughtworks，我们有一个第一年体验团队，由运营团队成员组成，他们将部分时间专门用于创建和执行有效的入职体验。他们既是内容的管理者——确保关键信息与当前的业务方向保持一致——也是入职培训和其他入职活动的协调者。对于较小的初创公司，这种协调和执行可以作为运营部门经理的兼职责任进行管理。
正如我们在之前关于 产品与工程文章 中提到的，职能经理作为一个团队合作以实现整体目标的价值也适用于入职流程。如果你即将快速发展，或者你已经发现入职效果不佳，我们建议创建一个工作组来关注流程并进行优化。弄清楚流程和内容将使你更清楚地了解你正在做的事情。
应该明确各个部分的归属。确保新员工了解愿景是领导层，通常是创始人的责任。随着规模的扩大，这将被编纂成文。无论如何，创始人仍然应该找到方法，亲自提醒大家使命。创建新员工入职培训或设置第一周体验将涉及许多不同的参与者，但由运营部门的某人（协调员）负责。
为了持续改进，应该有人负责收集和传播反馈——如果某些文档不清楚，或者某个系统不是完全自助的，那么这些改进任务需要被跟踪和完成，这很可能由“协调员”来管理。可以通过对新员工进行调查（建议在 3-6 个月后进行调查）以及征求将新员工纳入其团队的直线经理的意见来收集反馈。
我们在消除摩擦时经常会遇到的一个陷阱是“掩盖裂缝”。如果某些事情对新手来说很困难，请记住要寻找根本原因。例如，如果架构难以理解，可能是因为它文档编写得很差，或者它可能支离破碎或过于复杂。
除了定性反馈之外，还有一些定量指标（在“迹象”部分提到）也很有用。这些指标大多是基于产出的：新员工能否使用工具并完成他们所需的工作？这些指标并不能告诉你他们为客户创造的价值或代码或设计的质量，但它们可以帮助发现流程和环境中的摩擦。最好将这些指标用作工程组织的汇总指标，并跟踪随时间的趋势，而不是用于个人绩效。
- 首次提交到生产的时间
- 员工何时开始独自值班
- 第 10 次有价值的提交时间
- 产品经理的第一次客户访谈
- 设计师的第一次验证实验
投资于入职流程
第一阶段
实验
一个小型紧密的团队，不需要正式的入职流程
记录产品和技术设计，这对未来的员工理解很有用
第二阶段
获得牵引力
由运营部门领导的跨职能团队创建入职计划
自动化工作站设置、环境创建，创建 CD 管道。
建立涵盖技术、产品和业务的自助知识管理方法
创建合理的默认实践
第三阶段
(超)增长
建立围绕笔记本电脑采购、员工反馈、离职面谈、自动入职 HR 系统的流程。
实施持续改进计划，赋予团队权力消除日常摩擦
专门的平台团队致力于开发人员体验，KPI 包括首次部署时间
第四阶段
优化
专门的员工负责处理入职流程及其持续优化。
整合分散的知识体系
领导层持续参与入职，以激励新入职的员工
