对产品节奏的思考：YouTube 团队在增长期间如何扩展的内部视角

作者注：本文档最初写于 2015 年，反映了我在 2008-2014 年共同领导 YouTube 团队期间的 YouTube 流程。由于我在 2014 年离开，我被许多人要求写下我们在快速增长期间使用的一些关键流程。这里的一些见解已被许多其他团队采纳并应用于他们的扩展过程中。根据他们的经验，我正在着手扩展这个概念的版本（工作标题为“伟大团队的仪式”）。如果您有认为应该包含的想法/反馈，请与我联系。与此同时，祝您阅读愉快！

快速总结

我们在 YouTube 实验了很多的事情，其中之一就是节奏——如何最好地建立团队的韵律。

本文件分为三个主要部分：

宏观节奏 = 26 周 / 6 周

节奏：每 6 个月（26 周）进行战略规划，每 6 周进行冲刺规划
战略规划：结构化的 H1/H2 规划周期，结合自上而下的讨论和全面的自下而上的评审，最终形成大石头和项目分配
冲刺规划：尽可能轻量，专注于协调和承诺

每周节奏 = 4 种会议，包含大量的 Bullpen 和 Broadcast 邮件

类型：群组信息共享、决策、标签、1 对 1
广泛使用 Bullpen 和 Broadcast Email 来替代和缩短许多会议
关键理念：避免临时会议，做好准备并期望他人也做好准备，避免重新安排，不要害怕取消，选项/选项/选项（并避免“新选项生成器”）

实现思路

风格：在申请之前考虑一下你的风格 – 特别是你是更喜欢触手还是委派
技巧：一些重要的节奏技巧，比如共享的笔记/目标，为每次会议写下你的单一目标，定期审查会议以进行审核，减少、汇总会议时间分配，给你的日历上色，打印你的预读（打印 4 个一页？），保持一致的个人日程，以及一些给你的行政助理和/或幕僚长的建议

1. 宏观节奏 = 26 周 / 6 周

谷歌以其季度 OKR 流程而闻名，我们非常喜欢其中的一些特点（例如设定可量化但有抱负的目标），但季度节奏对我们来说感觉有些尴尬。我们面临两个挑战：

使用期望目标来管理依赖关系：OKR 过程的核心特征之一是“期望”目标——即你只应该达到目标的 70%，如果超过了，那就是你设定的目标太低了。但它们也用于跨团队协调（团队 A 依赖于团队 B 做某事，并通过确保这项工作“在他们的 OKR 上”来验证他们会做到）。这导致了许多困难的情况，因为团队不当使用 OKR 来跟踪依赖关系，最终对合作团队感到失望。
尴尬的长度：13 周（即一个季度）处于一个尴尬的中间位置——它太长，无法真正“承诺”，因为事情在 3 个月内可能会发生很大变化，但又太短，无法实现有意义的战略目标。我们发现它并没有很好地实现这两个目标。

所以我们决定将这个过程分为两个阶段 – 6 周和 26 周。

1.1 总体：每 6 个月（26 周）进行战略规划，每 6 周进行冲刺规划

我们的系统专注于两个独立的过程：

战略规划每 6 个月（26 周）进行一次，称为 H1 和 H2 规划。主要有两个关键输出：大石头列表和项目/资源分配。这需要一段时间（通常是 2-3 周的高度集中），并且非常全面（公司中的每个团队都参与其中）。
冲刺规划的频率大大提高，约为 6 周一次。这是每个团队对接下来 6 周内要完成的任务所做的真实承诺，并反映了团队之间的依赖关系。这个过程本应是一个非常短的规划过程（几天），但我认为我们仍在努力使其变得轻量化。

1.2 H1/H2 战略规划过程 => 大石头和项目分配

每六个月我们进行一次战略规划过程。

输出

在流程结束时，我们将发布两件事：

大石头：O(6) 大石头的列表。这些是未来六个月的关键关注点 – 优先于其他目标的目标。这些在一份总结文件中进行了描述，然后每个大石头团队会准备一个“推介演示”，在启动全员会议上进行展示，并附上一个总结“海报”，概述他们对该大石头的期望。.
项目分配：一个大电子表格，每个团队一行，链接到他们的“两个页面”，以及接下来 6 个月的人员分配。作为参考，在 YouTube，我们有大约 1000 名工程师分成大约 70 个团队（分为 12 个“投资领域”，然后再分为 4 个“重点领域”）。这个电子表格作为一个动态文档，记录了组织中每个人被分配到哪个团队，以及每个团队可用的人员记录。它对整个公司开放，人们经常参考它。

实现这些输出的过程是自下而上和自上而下同时进行的。

自下而上的过程 = 两页评审

在这个过程的开始，我们进行了一个非常密集的过程，全面审查每个团队的状态和目标。每个团队写了一份“两页纸”（通常更像是 4-5 页），涵盖他们在过去六个月中取得的成就，以及他们希望在接下来的六个月中关注的内容。在我们完善这个过程时，我要求每个人特别指出 3 件事：

你想确保 Shishir 知道的三件事
让你更快移动的三件事
你痴迷的{图表、图形、图片等}

最后一个（“痴迷”图表）被证明是一个非常好的机制，真正理解团队的驱动力。有时团队会选择一个单一的指标（“我们希望这条线超过值 X”），而其他团队则会选择一个激励性的图片或句子。例如，我最喜欢的之一来自我们的 Video Knowledge 团队，他们的任务是尽可能多地了解视频中的内容。他们的“痴迷”是一个视频，下面有一句话：“这是一个孤独的绅士上个月在巴黎桥上独自漫步，静静地思考自己的想法”。他们的目标是能够利用机器学习达到对视频的那种理解水平。

这个过程顺利进行的一个关键部分是非常快速的评审。我们有大约 70 个团队需要评审，每个评审可能轻松花费 3 个小时，但我们希望在一周内完成，以尽量减少对整体工作进度的干扰。我们通过让每个团队提前几天发布他们的两页材料来实现这一点，然后我（和其他团队领导）会仔细预读所有材料。每个团队的评审大约为 10-15 分钟（按投资领域分配在大约 3 小时的时间块内），评审期间没有进行演示。我通常会带着一份我对团队有的几个重点问题的清单参加会议，我们就会逐一讨论这个清单。我尽量确保至少完全理解他们希望我知道的 3 件事，以及能让他们更快推进的 3 件事，但通常会在他们的书面材料的其他领域提出问题。

团队通常很喜欢这些会议，并投入了大量精力确保材料制作得很好、全面但简洁。撰写总结也是团队记录目标和计划的一个很好的推动力，团队成员、新员工等经常参考这些总结。

对我个人而言，这一直是我一年中最喜欢的几周之一，因为它很好地提醒了我们各个团队所做的精彩工作。有些团队经常处于聚光灯下，但大多数（绝大多数）团队并不是——所以这是一个很好的机会，确保他们的工作得到充分理解并保持在正轨上。团队们经常评论他们有多么重视这个过程带给他们的反馈和可见性。

公平地说，这个过程需要大量的时间投入，但对我来说，这非常值得，而且参与的团队也经常给予积极的反馈。

自上而下的过程

除了自下而上的过程，我们还从自上而下的角度做了一些事情。特别是，我们在自下而上的过程中进行了几次早期的启动讨论，然后通过自上而下的过程做出了最终决策。

与技术人员的启动头脑风暴会议：在流程早期（大约在两页审查前的两周），我们会与技术人员举行几次头脑风暴会议。

在第一次会议上，我们会回顾过去六个月的感受，并讨论未来的优先事项不同选项。然后我们会开始一个共享的电子表格，邀请每个人添加我们在接下来的六个月中应该优先考虑的想法。我们会进行一次“投票” – 每个人在电子表格中都有一列，并将 100 分分配给每一行。然后我会快速浏览并挑选出一部分项目，以便我们在下次会议中继续讨论 – 投票被视为一种反馈，但大家都觉得我可以覆盖它，通常是通过添加一些没有得到投票但我仍然认为重要的内容。
在第二次会议中，我们将看到关于我们从第一次会议中选择的每个项目的简短单页演示。这些通常都是比较高层次的——重新框定在上次会议中可能不够清晰的目标等。在这些演示之后，我们将再次投票（相同的技术），我会再次选择一组项目继续推进，使用投票作为输入但不是规则。

跨职能输入会议：然后我们与每个职能进行了系列会议，以获取他们的意见——销售、市场营销等。每次会议的流程是，首先该职能的领导会提出一个未提示的潜在优先事项列表，然后我们会查看技术人员的练习结果，看看偏差在哪里。大多数时候，偏差很小，因为我们通常会持续听到这些意见，但偶尔这些意见会导致变化。
结束离线会议：在所有两页评审完成后，我们召集技术团队进行最终决策。此时，许多数据已经清晰——我们的整体人员预算应该是多少，我们需要考虑多少“自然”增长，等等。在会议之前，我通常会提出一个潜在大石头的讨论列表——通常是基于我们最初的离线结果和我们在两页评审中看到的内容。对于每一个大石头，我们会指定一个“石头经理”。这个石头经理的任务是更精确地定义这个石头，并列出他们认为需要的团队（如果可能的话，列出个人的名字）以便在这个石头上取得成功。在会议期间，重点是对齐矩阵——每个重点领域会提出他们希望分配资源的地方，然后我们会查看每个石头经理的请求。不可避免地，我们会有太多的石头无法分配人员，但这帮助我们看到了真正的冲突所在。然后我们会进行连续的群体讨论，然后分组尝试调和这些问题。最后，我们通常达成共识，但如果需要打破平局，我会做决定。
最终总结：即使在做出决策的外部会议之后，仍然需要一轮总结来向组织的其他成员解释这一切。我会起草一封总体邮件，涵盖所选的关键项目（以及原因），每个团队会根据我们的决策填写人员规划的电子表格，每个关键项目经理会准备他们的总结“海报”。然后我们会通过电子邮件发送材料，并在第二天召开全员会议，由每个关键项目经理展示他们的海报并回答问题。

常见问题

我经常听到的一些关于这个规划过程的问题：

为什么大石头？关于这个有很多文章 – 尝试这个有趣的解释.
多少个大石头才是正确的数量？这非常棘手，我们对此反复讨论。

让我们先从一个简单的问题开始：大石头是否全面涵盖了团队正在做的工作？换句话说，团队中的每个人都被分配到一个大石头团队吗？我认为这是一个自然的陷阱。典型的模式是团队 X 的努力 Y 被遗漏在大石头列表之外。他们提出“为什么不把 Y 加到列表上呢？我们反正要做这个，它不会影响其他人，等等 – 有什么大不了的？”我会强烈抵制这种冲动。
所以我们为大石头开发了一些试金石。特别有三个，我们按以下顺序排列：

最重要的优先事项 – 如果我们不做其他事情，我们应该确保这 N 件事发生
解决竞争资源的冲突 – 选择正确的大石头将有助于澄清一些团队的优先事项，这些团队总是处于多个优先事项的中间（例如，客户团队）
全面了解各个团队正在做的事情 – 这点最不重要

考虑到这些规则，我们通常会有大约 5-7 个“大石头”。此外，由于我们分配了“大石头团队”，我们可以评估团队中有多少百分比在处理“大石头”，而不是专注于他们职能领域的优先事项。这个数字通常在 30-40%左右，这意味着 60-70%的团队工作不包括在“大石头”之内。
等一下，大石头只覆盖了你资源的 30-40%？难道不应该更多吗？

不，我不这么认为。将“100%的资源投入到前五个项目”是非常诱人的。但根据我的经验，这通常会适得其反。
事实是，总有一些组件/团队需要取得进展，有时只是为了维持生计——例如，仅仅因为我们不想在一个周期内过于强调 ContentID 并不重要——为了跟上自然增长，他们必须重建系统。
所以如果你坚持要把大石头覆盖到你所有的倡议上，你就会不情愿地被引向相反的方向——换句话说，你会被迫重新表述你的大石头，使其涵盖一些实际上并不是最优先事项的内容，而这并不是你真正打算解决冲突的方式。

这只是技术还是跨职能的？我们试图使其跨职能，但它绝对是以技术为驱动的。在我看来，这并不可取，只是这个过程发展的产物。如果我在一个新组织中再做一次，我会尝试更加跨职能。
Big Rocks 的所有权/团队模型？在最初的几个周期中，我们会选择 Big Rocks，但只是让我们正常的领导团队（通常是技术人员的成员）来管理这些 Big Rocks。这有一个优点，就是有一个向我汇报的人对这个 Rock 负责，但缺点是那个人通常是个 Chicken 而不是 Pig。然后我们转向了一种指定特定 Rock Managers 的模型，以及一个“Hoodie 团队”来支持他们。Rock Managers 通常是受影响最大的团队的跨职能负责人（例如，PM 负责人、工程负责人、用户体验负责人，有时还有市场负责人、销售负责人等）。 “Hoodie”团队被定义为来自多个团队的 Pigs，他们在这个 Rock 上工作 – 这个名字的来源是因为一个试金石问题：“如果你要穿上印有你所在团队名字的连帽衫，你会穿哪一件？”
为什么在这个过程中进行资源分配？团队对此有不同的看法，但我喜欢将资源分配作为这个过程的一部分。主要有几个原因：

这迫使真正的优先排序——如果没有成本，什么都是优先事项，这太简单了。
通过每 6 个月分配资源，实际上避免了在其余时间内对资源分配进行大量讨论。我们保留了一部分可以分配的资源，但大多数主要的资源请求通常发生在 6 个月的边界上。

1.3 Sprint 规划：尽可能轻量，专注于协调和承诺

冲刺计划的目标类似于 scrum-of-scrums 模型。存在两个并行的过程：

团队级冲刺规划：每个团队都会进行自己的规划练习，并优先考虑他们在 6 周内的目标列表。每个团队的做法略有不同，这没问题。至少，每个团队需要发布他们的目标列表（通常为 4-5 个），以便进行第二个过程。
依赖协调：然后团队会聚在一起讨论彼此之间的依赖关系。我们为此使用了一个（相当复杂的）电子表格。

就这样 – 这个过程尽可能轻量。

一个常见的问题是我们为什么在 6 周时这样做。限制因素是 Apple 应用提交过程——考虑到这个过程的开销，做得少于 6 周是很困难的。如果可能的话，我更希望是 4 周。

1.4 宏观层面的总结与思考

分割这个过程有一些影响：

每个团队至少每六个月进行一次深入评审。这确保了每个人都感到被纳入其中，对于领导者来说，这意味着你可以完全了解公司发生的事情。
减少资源焦虑。因为我们每 6 个月才进行一次宏观资源分配，所以在这个周期之外“随机请求人手”的情况少了很多。

当然，也有一些缺点:

并不是所有事情都符合六个月的周期。因此，有些讨论看起来过早（我们还没准备好决定 X 是否应该是一个 Big Rock），而其他讨论则显得有些过头（这个工作只需要 1 个月，没错，它非常重要，但我们真的想在这上面花一个 Big Rock 吗？）。
需要保持警惕的管理。如果不对团队进行期望和沟通的严格管理，这些流程很容易膨胀成许多低价值的过程。我们每个周期都尝试优化流程，剔除不必要的部分，专注于真正重要的事情。

2. 每周节奏 = 4 种会议类型 + Bullpen + 广播邮件

在制定宏观策略后，接下来要关注的是每周的节奏。我们花了很多精力尝试不同的模式。

一些核心原则是：

避免临时会议：最糟糕的情况是日历上满是临时会议。每个会议都需要协调与会者的日程，这可能会推迟讨论。但更重要的是，缺乏明确的结构往往会导致无效的会议——人们不知道这是信息共享会议还是决策会议，也不清楚需要什么级别的准备等。通过创建合适的定期论坛，留出足够的时间和合适的与会者，避免这些情况是关键。
定义四种会议类型并相应地进行结构化。人们将学习每种会议的模式和规范——议程如何设定，所需的准备工作量等。
使用“Bullpen”时间和广播邮件来缩短和替代许多会议。
做好准备，并期待他人也做好准备：我们几乎从不在会议上“展示”任何东西。材料总是提前发送，大家都需要提前阅读。这需要适应，但一旦成为文化的一部分，就能节省大量时间。这也意味着我们几乎所有的会议都安排为 30 分钟（即使是员工会议、复杂的产品评审等），并且通常会提前结束。
避免重新安排：我的幕僚长一直强调这一点。首先，他向我展示了每次我调整会议时间时，对整个组织产生了巨大的蝴蝶效应，因为他们需要调整自己的日程以配合我的，然后这种影响会在团队中层层传递。其次，一个团队或个人对会议的准备程度与他们对会议实际发生的期望成正比。如果我经常重新安排会议，我就应该预期人们会准备得更少。
不要害怕取消：设立常设论坛并让人们提前发送材料的一个好处是，在会议之前通常可以清楚地知道是否有理由开会。我们经常通过电子邮件发送议程，解决剩余问题，然后取消会议。

2.1 四种会议类型

我们定义了以下四种会议类型：

群体信息共享：这些会议可能会比较大，主要用于广播和协调。最重要的是，这些论坛不是决策论坛。例子包括我们的每周员工会议、统计会议和全员会议。

牛棚：我们经常用“牛棚”来补充这些——一种非结构化的时间，大家都需要留在这里（即使只是用笔记本电脑工作）。我们避免了许多临时会议，因为人们会说“我们在牛棚里聊聊”。
广播邮件：我们发现自己在这些论坛上花了太多时间，只是在等待彼此的更新，因此我们设定了一种通过广播邮件发送一些内容的模式，以便这些会议能够保持简短。例如，我在周日晚上向 yt-tech-staff 发送了一封总结邮件，内容包括过去一周的总结和本周需要关注的关键事项——然后当我们到达周一早上的技术人员会议时，我们可以专注于大家的问题。我们的每周员工会议只有 30 分钟（！）加上 1 小时的讨论时间。

决策论坛：这些会议是专门为决策而创建的。会有一个非常小的必需的常驻参与者群体，并且每次会议都会组建一个新的相关听众 – 通常会有一个广泛的可选参与者名单。会提前通过电子邮件发送一份描述决策（及考虑中的选项）的文档，以使过程更加顺畅 – 而且通常在会议举行之前，决策就在电子邮件线程中得以达成。例子包括产品评审和交易评审（称为 YTX）。
Tag-ups：我有时称这些为“组 1-1”。例如，我们会与每个投资领域的领导团队进行每周的 tag-up——PM 负责人、工程负责人和 UX 负责人（以及其他相关的跨职能同事）都会参加。当我注意到我会与工程负责人进行 1-1，并想讨论一些确实需要 PM 负责人参与的事情时，就创建了这些会议。我们使用“Tag-up”这个术语来指代任何会议，其中（a）与会者是固定的（几乎不会添加嘉宾），（b）每周在固定时间安排（且不会重新安排），（c）有“滚动”议程（有一个包含议程和行动项的文档，如果时间不够，你会在下次会议中回到滚动的议程项和行动项）。这些会议通常可以相当随意（就像 1-1 一样）。
1-1s：由于 tag-ups 接管了任何项目特定的讨论，这使得 1-1s 完全以辅导为中心（实际上，我会定期将 1-1s 中的话题推迟到 Tag-ups，因为它们需要其他与会者）。我与一组核心人员（基本上是我的直接下属和一个间接下属）有固定的 1-1s，然后保留灵活的时间供任何人预约与我会面。

将会议分为这四个类别的一些关键优势如下：

将群组信息共享与决策论坛分开：这是一个关键的决定——例如，这意味着我们在员工会议上不会尝试做出许多重要决策。请注意，这不仅仅是与会者的错误——通常，决策审查会议的可选与会者名单会包括来自某个群组信息共享论坛的所有人（例如，YT-Tech-Staff 的所有人都是产品审查的可选与会者）。但分开这些论坛是非常重要的，因为会议的语气和期望截然不同。一些影响：

更专注的出席：如果你与决策论坛中正在做出的特定决策无关，你可以放心地跳过（但例如，如果你经常缺席员工会议，那就不太行）。因此，参与审查的人通常对结果都非常感兴趣。
减少组织结构所造成的“等级制度”。在许多组织中，决策通过组织图向上升级，经过逐渐更高级别的员工会议进行审查。在这种情况下，我们传达了一个明确的信息，即员工会议是关于协调、传播等的——但你参与决策的能力与是否参加该员工会议无关。
决策会议非常专注 – 通常是在为一个明确表述的问题选择一组明确定义的选项之一。因为材料总是提前发送，并且之前有一个小组邮件线程，所以在决策论坛中进行决策讨论比在员工会议中进行更受欢迎。

将 Tag-ups 与 1-1 分开：在一个技术组织中，你的大多数团队都有一组跨职能的领导者。如果你在 1-1 中进行项目评审和战略讨论，那么你几乎总会陷入“电话游戏” – 例如，某个项目的 PM 负责人会回去对他们的工程对应者说“Shishir 在我们的 1-1 中说了 xyz”，然后工程对应者会将其添加到他们的 1-1 中与你讨论的列表中。
将固定的 Tag-ups 替代临时会议：记住核心目标是最小化临时会议。一个非常常见的请求是“我们能否安排一个会议来讨论问题 X？”我自然的思维过程是首先询问是否有一个自然的 tag-up 来讨论这个话题，并建议使用这个。这样做有很多好处。首先，它确保了合适的人聚集在一起进行讨论，而无需进行新的日历协调过程。其次，也许更重要的是，它导致了自然的优先排序——如果这个话题在那个 tag-up 中不够重要，那么它很可能也不够重要去召开临时会议。

2.2 在我们开始之前，YouTube 会议的整体地图

接下来的几个部分将介绍我们在 YouTube 举行的具体会议（遵循“4 种类型”框架）。作为整体地图，这里是每个会议的摘要表，可以作为参考。

这张地图准确总结了我常规的 YT 日程，除了我已经去掉了实际人员的名字和机密团队名称，并用占位符替换。

还要注意，这些数字反映了每周在该会议上花费的小时数，会议旁边的文本符号反映了它的频率（W = 每周，Bi = 每两周一次，等等）。所以例如，0.25 Bi 意味着这是一个每两周举行一次的 30 分钟会议，导致每周的会议负担为 0.25 小时。

附录中有更大版本。

请注意，我每周大约有 30 小时的预定会议。因为我非常努力地不在此基础上增加临时会议，并且有足够的候补和灵活时间，我发现这是一个紧凑但可管理的日程。

2.3 群组信息共享 (G.I.S.) 会议和公用工作区

我们的主要 G.I.S.会议是我们的员工会议。我们有 3 个独立的“员工”论坛：

YT 技术团队（和技术团队候补）

这是我主要的员工会议，包含了我所有的直接项目经理、工程师、用户体验领导，以及一些关键的间接人员（例如我们的测试和基础设施负责人，我们的区域技术负责人等）。这个小组大约有 20 名成员，大家一起花了很多时间。
会议本身是在周一早上进行的，持续了 30 分钟，由我的幕僚长负责。
在会议之前，通常是在周日晚上，我会发送一封冗长、坦诚且直率的邮件，概述上周发生的事情以及我认为下周的关键优先事项。这封邮件并不是为了转发，我非常坦诚，所以大家总是非常仔细地阅读它。
会议的常规议程项目是审查发布日历，查看本周有哪些项目按计划发布，以及处理我每周邮件中的任何问题。有时还有其他议程项目，特别是在绩效评审季节或 H1/H2 规划期间，但通常会议的正式部分会提前结束，我们会转到开放式办公区。
技术人员休息区在员工会议结束后立即开始，通常非常活跃——规则是你必须留下来，即使你只是用笔记本电脑工作。通常，人们会利用这段时间进行跨团队的临时讨论。

YT Biz Staff – 这是罗伯特与所有“业务”领导者（特别是内容、销售、市场营销）的对应会议。议程由罗伯特的幕僚长提前发布，会议通常持续一个小时。罗伯特和我互相参加对方的会议，以确保技术和业务方面保持同步。
YT 员工（和 YT 员工候补）

这是一次跨职能的员工会议，参与者包括技术人员、商务人员和其他一些人。
这是一个非常大的会议 – 超过 60 人被邀请。
议程是审查一组基本指标（收入、观众人数等），然后讨论即将推出的产品/活动的更新，并回顾一些最近推出的产品/活动的结果。这个演示文稿是由我的幕僚长和我们数据科学团队的负责人共同制作的。
会议定于星期三举行，持续 30 分钟，尽管通常会提前结束。会议后是一个 Bullpen，遵循与 Tech Staff Bullpen 相同的规则。
关于这个会议的实用性总是有很多争论，考虑到它的规模，我们尝试了许多变体。我的观点（虽然不是普遍共识，但大多数人持相同看法）是，这个会议有其良好的目的，至少因为它迫使每个人聚在一起进行 YT Staff Bullpen。这个 Bullpen 非常有用，因为这种跨职能的互动通常很难实现（例如，二级内容负责人与个别工程负责人讨论问题）。

其他主要的 G.I.S.会议包括：

全员会议：在我所在的层级，我们每季度举行两次——一次是针对技术团队（产品、工程、用户体验），一次是针对所有 YT 员工。我们曾讨论过是否要更频繁地举行，但最终决定不这样做，因为（a）Larry/Sergey 每周五都举行 TGIF，参与人数很多，所以再加一个似乎太多了，以及（b）我们希望鼓励每个团队（例如，观众团队、内容团队等）自己举办更频繁的全员会议。也就是说，如果我再做一次，我会更频繁地举行——至少每月一次，如果不是每周一次（像 Google 的 TGIF）。
YT 统计：这是我在 YT 参加的最喜欢的会议。

这是由我们的数据科学团队每周五运行 90 分钟，他们简单地展示了一小部分深入的基础内容，然后是有趣数据发现的长串演示。
我们通常在 90 分钟内完成 100 多张幻灯片（每张幻灯片有 4 个以上的图表），主要是因为数据整理得非常好，故事也很有逻辑。
最初是一个小组会议，但逐渐越来越多的人想参加，我们最终开始在世界各地的许多房间进行视频会议以便能够参加。会议上通常会有 100 名与会者。
虽然这不是一个正式的决策论坛，但对于大型发布来说，通过这个论坛是一个“要求”。例如，如果你要发布某个会显著影响指标的东西，你就需要带到这个论坛。团队通常会对指标进行更深入的审查，并进行“赢家/输家”分析，以查看谁会受到发布的积极或消极影响。
如果出现问题并需要进一步讨论，我们通常会指明应该在哪个论坛进行后续讨论 – 例如，相关的标签讨论，或者对于更重要的问题，产品评审。
点心：这是在 YT 变现早期非常有趣的传统。大约每隔一周，我们会去一家当地（非常非常好）的点心餐厅。这并不是由谷歌支付的（感觉这传达了“你完全不需要来”的正确氛围），对团队中的任何人都有开放邀请，通常会有 20-30 人参加。尤其是在早期，我们会选择一个话题在午餐时讨论——例如，TrueView 这个名字就是在那里诞生的。

总的来说，我每周在这些论坛上花了大约 6.5 个小时，但其中包括 2 个小时的主要是临时的 BullPen 时间。

2.4 决策论坛

首先关于这些论坛运作的一些说明：

做好准备，并期待他人也做好准备：正如我上面提到的，我们几乎从未在这些会议上“展示”过任何东西。我曾经有一个新人在会议上开始展示，我的一位高级工程师靠过来对我说：“你打算让他这样做吗？” 🙂
选项、选项、选项：任何读过《Decisive》的人都会认同这种哲学——我们坚信，做出艰难的决定需要列出选项。如果你来到一个论坛，只有一个选项的决定，你通常会了解到这不是我们做决定的方式，可能你的同伴会向你解释这是如何运作的。
附带的烦恼：新的选项生成器 – 我有一个烦恼，当领导在审查过程中最后说“我认为你不应该做你列出的选项 A、B 和 C，我认为你应该做 D，这是我刚刚想出来的。”由于材料总是提前发送，如果我觉得选项不完整，我会回复邮件，团队会在会议之前做出反应，而不会感到惊讶。

有三个主要的决策论坛：

产品评测：针对技术问题

这是我拥有的，基本上涵盖了任何“技术”问题[非技术问题转到 YTX，见下一个论坛]。对于技术问题，这个论坛是最终决策论坛，人们期待从这些评审中得出结论。
与会者名单总是由请求审查的团队自定义生成，但任何在 yt-tech-staff 上的人总是可以选择性参加
会议安排在周一（有一个适合 EMEA 的早晨时段，以及一个下午时段）。我的第一任幕僚长（Matt）实际上说服我在周一举行这些会议（而不是更经典的周五安排）——他的理念是“通过在一周的第一件事上做出一些决定来为这一周定下基调”。我完全同意这个理念——没有什么比一个好的产品评审更能让一周的开始感觉更好。
它们通常持续 30 分钟，尽管有时人们会要求更长。不过它们经常提前结束——尤其是当邮件线程大部分已经达成决定时。
审查的材料将于周四通过电子邮件发送。抄送了一个非常广泛的群体——包括每个 YT PM、每个技术负责人等——超过 100 人会看到这封邮件。人们会在周五和周末期间回复和评论。到周日晚上，我通常会阅读材料以及每个人的评论，并发送我的总结。我的总结通常会成为实际会议的议程——我们会假设每个人都已阅读材料并跟踪邮件线程，然后讨论我要求更多讨论的要点。
我们总是带着一个决定离开——即使这个决定是明确的“我们不会在收集到{X 数据，构建 Y 原型等}之前做出这个决定”。

YTX 交易评审：针对商业问题

这由罗伯特拥有，涵盖了任何“商业”问题。
它通常由交易审查主导 – 内容涉及与新合作伙伴的交易、销售定价/折扣等。分配了一名合规人员，并有一个升级流程（针对较大的交易）以进入谷歌范围内的交易审查论坛。
它遵循了类似的模式，提前几天发送幻灯片，而不是在会议中花时间让某人进行演示。
与产品评审不同，这个论坛的参与者是固定的，邀请名单也要狭窄得多。这既是由于评审的合规性质，也（坦白说）是因为我和罗伯特的风格不同。
这个论坛运作得很好，我们总是能达成决策，通常伴随着良好的健康辩论。

YT Eng Review: 有关更详细的技术问题

这是由我们的高级工程师“架构师”拥有的（我们称这个角色为“区域技术负责人”）
它涵盖了通常过于具体以至于不适合产品评审的技术实施问题。这个论坛通常在产品评审之后进行（产品评审设定方向，然后工程评审审查具体的实施选择），有时也会在之前进行（在工程评审期间，我们会确定一个问题对产品的影响更广泛，并将其升级处理）。
有一个核心的工程领导小组，他们是可选的与会者。
会议的流程与产品评审相似，都是在评审前提前发布书面材料并进行冗长的邮件讨论。

总体来说，我每周在这些论坛上花大约 4 个小时，尽管有些周如果我们通过电子邮件解决了问题，可能会少一点。

2.5 标签提升

这些可能是我们最独特的会议类别。正如我上面所描述的，我们将这些视为小组 1 对 1，并为任何我们认为需要持续协调的团队创建了这些会议。它们分为几个自然类别：

重点领域标签会议：YT 技术团队被分为 4 个重点领域（观众、创作者、广告、核心工程）。每个领域每周有一个小时的会议时间。与会者通常是该领域的产品经理、工程师和用户体验负责人，在某些情况下，他们的跨职能对应人员（例如，广告领域的销售负责人参加了广告会议）。会议的模板分为 4 个部分：

人们 – 他们会概述团队中的任何新成员或离职人员、任何重组/重新分配，以及任何新出现的人事问题
发布和决策 – 然后他们会迅速回顾作为团队所做的任何重要决策，并向我介绍即将发布的内容以及最近发布的回顾。这些团队非常庞大，因此这个列表可能会很长，所以细节的把握取决于团队，大多数团队在筛选出需要我反馈的发布和决策或他们认为我需要了解的内容方面都做得很好。
指标 – 对该领域相关指标的快速概述（通常很快，因为我自己定期查看仪表板）。
讨论主题 – 团队会选择一组主题进行讨论。通常这些主题比较随意，尚未形成具体的框架，他们在寻找方向性的反馈。有时他们只是进行头脑风暴，我们会一起在白板上讨论。偶尔也会有一些较小的决策主题，不需要产品评审（但这不是常态）。

大石头标签会议：我们还为每个大石头设立了一个每周论坛。这些论坛的模板与 FA 标签会议非常相似，每个大石头的领导者会准备关于人员、发布/决策、指标和讨论主题的更新。岩石经理会确定标签会议的与会者，我们尽量保持小规模（理想情况下少于 5 人，偶尔少于 10 人）。
跨职能标签会议：我发现有几个职能需要定期时间来讨论话题：

人力资源/招聘 – 我会对我们提供录用的每位候选人的材料进行审核，协调绩效评估流程，讨论人员问题等。
法律 – 法务团队总是有一份需要专门论坛讨论的主题列表。他们也经常会询问我关于他们正在追踪但缺乏背景的某个问题的情况。
财务 – 这是我们处理预算问题的地方，查看财务预测等。
市场营销 – 我们会审查和分类市场营销优先事项，审查活动等。

功能领导标签会议：我倾向于主持跨职能（PM、工程、UX）的大多数会议，因此我们需要几个特定于职能的论坛：

工程领导 – 我们会讨论工程特定的话题，比如推送流程、代码库和工具选择等。
PM Leads – 这主要是关于协调 PM 分配到项目以及 PM 加入（和移除）团队的事。
ATL Tag-up – 我创建了一个叫做 Area Tech Leads 的角色。这些都是我信任的非常资深的个人贡献工程师，他们负责团队中的许多技术决策。我有 3 个（涵盖数据、发现和整体“应用”），我们会聚在一起协调他们应该关注的重点。

我的管理员 + 首席幕僚会议：每周我们三个人会坐下来对这一周进行分类。更多内容在最后一部分。
执行标签更新：最后一个是 Salar-Shishir-Robert 标签更新。我们三个人作为一个三人组一起运行 YT，因此我们会确保每周至少同步一次。我们通常在晚餐时进行这个，并讨论那些没有得到解决的棘手问题等。

在流程方面，每次 Tag Up 都有一个共享的 Google 文档，所有与会者会定期向其中添加主题。我们甚至构建了一个电子表格提取器，将其与我的日历对接，但那是另一个讨论的话题 🙂

关于 Tag-ups 的一个日程安排说明：我们为 Tag Ups 设定了一个日程，并且我们非常努力地不去更改它们。我的幕僚长坚持认为，如果出现冲突，我们会选择取消而不是更改。请参阅此日程顶部的核心原则，以获取更长的描述。

总体而言，Tag Ups 占据了我每周大约 11.5 小时的时间（几乎是我安排时间的 40%）。我发现这些会议非常有用且富有成效。

2.6 1-1s

最后一类会议是 1 对 1 会议。正如我上面提到的，我们创建了 Tag Ups，作为将产品/战略讨论从 1 对 1 会议转移到 Tag Ups 的一种方式。因此，这意味着 1 对 1 会议通常专注于职业指导和个人问题解决。我让对方控制议程——尽管我们为每个 1 对 1 会议保持了一个共享的 Google 文档，就像我们为 Tag Ups 所做的那样。一些代表性的指导主题可能包括：

我的报告，XYZ，正在努力学习如何处理情况 ABC。我可以告诉他们什么来帮助他们度过难关？
我在时间管理上很挣扎，怎么才能改善？
我似乎无法与我的同事 {eng, pm, ux} 负责人相处。有什么我可以做得不同的吗？
人们在会议上似乎总是打断我，我该如何克服这个问题？
等

决定和谁进行一对一会议是一个持续的斗争。每个人都将定期的一对一视为接触和地位的标志，但太多的一对一绝对会杀死你的生产力。定期的 Tag Ups 确实有所帮助，因为在那 11 小时的 Tag Ups 中，我每周可能与 50 个独特的人在亲密的环境中互动。

我有一个核心小组，频繁进行 1 对 1，结构如下：

直接汇报：每两周 30 分钟
关键间接报告：我通常将其限制在参加技术员工会议的同一组人（只是为了保持一致性），并将这些会议保持在每月或每季度的节奏。
关键跨职能负责人（内容、市场营销、销售、亚太/欧洲中东非领导等） – 每两周 30 分钟

我随后举行了一个单独的论坛来处理我无法定期安排的所有 1 对 1 会议：

Flex 1-1s：我每周留了 2 小时的灵活时间，分成 6 个 20 分钟的时段。人们可以自行预约，通常都被预约满。当人们要求与我进行常规的 1-1 时，我通常会告诉他们先使用灵活的 1-1，大多数人逐渐遵从了。

我也有一组 1 对 1 的会议，在这些会议中我是接受指导/反馈的“接收者”：

我的老板：Salar 和我每隔一周见面 30 分钟（但我们一直保持联系）。我们还每隔一周和 Larry 进行一次联合一对一。
我的顾问：我保留了几个关键顾问，并确保定期与他们见面。

总体来说，我每周花了将近 8 小时在一对一会议上（包括 2 小时的灵活时间），所以这也是一次有意义的时间投资。

3 实施思考

3.1 风格（或“这个模式适合每个人吗？”）

我经常收到的一个问题是：这个模式适合每个人吗？我的回答是：不，这很大程度上取决于领导者的风格。

我认为这值得对风格做一个简短的评论。领导者都有不同的风格，他们的节奏通常反映了这一点——所以我在这里的一些建议对不同的人可能不太适用。

[注意，当我说“风格”时，我指的是特征，而不一定是优点或缺点。]

特别是，我风格中的以下元素对我们的过程产生了很大影响，可能不适用于其他人：

更喜欢大型会议：你会注意到我们很多小组信息共享会议和决策审查会议都有大量与会者（注意：Tag-ups 的规模保持得很小）。

我发现一些领导者觉得大型会议非常令人沮丧。例如，拉里·佩奇曾推测，一个高效的会议中参与者不能超过 7 人。对我来说，这并不奏效——我喜欢让所有相关人员都在场。产品评审通常有 40 人参加，YT Stats 有 100 多人，等等。
这种方法的一个推论是，它需要认真管理会议——你必须仔细观察，以确保正确的人在发言/参与，当有人看起来有话要说但又犹豫时要及时指出等等。我会使用的一个机制，例如在产品评审中，是在会议前的邮件线程中，我会列出我希望在会议上听到的意见的名单（“明天我们聚在一起时，确保 X 先生对 A 主题发表意见，Y 女士对 B 主题发表意见”）。另一种方法是利用群众的智慧（“在座的有多少人认为我们应该选择选项 A”或“这是一个小组电子表格，每个人拿 100 分并在你选择的问题上分配”）。这需要付出努力，但这种方法的好处是你通常能直接从最相关的人那里得到答案——而不是像打电话游戏一样通过层层经理翻译和传递。
这种方法的批评者会说这是一种对委托的替代——关于这一点我认为有合理的论点，下面会详细讨论。
对预读和准备感到舒适：我们“做好准备并帮助他人做好准备”的风格需要在会议前花费大量时间进行预读。

为了使这一切有效，领导者必须树立榜样——如果他们偶尔错过预读，或者没有真正深入理解，那么其他人也会逐渐放松。例如，在 H1/H2 规划中的两页评审，这通常是一堆约 300-400 页的阅读材料（70 个团队 * 每个团队约 4-6 页）。
对我来说，让这项工作顺利进行的关键是我的管理员——我们协调好时间，知道我什么时候有很多阅读任务，她会预留时间，然后把所有内容打印出来给我阅读（通常是每面 4 页，双面打印，所以一张纸上可以放 8 页）。我在阅读时会在那些纸上做笔记，然后再回过头来在页面顶部写下我的简要想法。对于产品评测之类的事情，我会在会议前通过邮件发送我的想法，这样每个人都有机会消化和反应。
这个技术重要的原因有几个。

它帮助避免了我之前描述的“新选项生成器”模式——如果我认为他们没有足够的选项，我会告诉他们，他们要么添加它，要么（深思熟虑地）告诉我为什么那个选项不可行。
这迫使我深入思考这个问题。一般来说，如果一个问题重要到需要提给我，那么我认为在 30 分钟会议开始时第一次听到这个问题并在结束时做出决定有点自信。如果它重要，就需要思考，这迫使我在反应之前先考虑这个问题。
它迫使我写下我的看法。接下来会有更多内容。
这种方法的批评者会说，这是一种拐杖，让团队避免进行综合——也就是说，因为人们会阅读一篇长文，他们可以少做综合。在我看来，我通常看到的是相反的——强迫写下东西帮助人们澄清他们的想法，而不是依赖他们的面对面辩论能力。
愿意写下一个观点和思考过程：对我来说，写作的过程比说话要严谨得多——在会议环境中，人们会接受一些推理的跳跃，而在书面文件中你绝对不会接受这些。（参见杰夫·贝索斯对写作价值的论证）

所以我提前发出我的想法的部分原因是为了确保 (a) 我真的认真思考过某件事，以及 (b) 帮助人们看到思考过程，而不仅仅是决策。
第二部分特别重要。我的观点是，好的决策是那些“持久”的（即经得起时间的考验），而绝对最好的决策是那些能够阐明一种哲学，使得接下来的 10 个决策变得容易得多。因此，记录下决策的思考过程是非常重要的。
评论家……我认为对此没有太多评论家。

喜欢被质疑，并渴望辩论：我们的大部分过程都是为了引发辩论——广泛发布预读材料等等。而记录我自己的思考过程可能会让我感到非常暴露——因为这也邀请了辩论。对我来说，这很好——我身边的人了解到我在辩论某件事时表现最佳，这就是我理解问题的方式。批评者会称这耗时且过于繁琐，因此这总是一个平衡。
更喜欢上下文切换而不是单一专注：从我的日程安排中可以看出，我有很多天在 8 到 10 个完全不同的话题之间切换。对于一些领导者来说，这大大降低了他们的表现，但对我来说，这保持了我的能量水平（可能表明我有一定程度的注意力缺陷多动障碍）。批评者可能会说更多的专注可能更好，我确实见过一些“隧道视野”的领导者，他们在选择一个话题上非常有效，可能一天（有时甚至一周或一个月）都在深入研究，但这不是我的风格。
触手无处不在 vs 委托：这可能是最重要的特征，我确实认为这是一个真正的权衡。我的大多数团队成员可能会形容我在业务的许多领域都深度参与。这有一些非常积极的特征——它可以保持团队的积极性，因为大多数人都与我有某种联系，它让我能够看到其他人可能会错过的跨团队机会，它使得在可以或不可以做的事情上“忽悠”我变得更加困难，等等。但它也有一个不好的副作用，那就是可能让我的一些领导感到失去权力。在我的情况下，我的团队通常喜欢这种风格——他们发现我可以更容易地与他们强化信息并帮助他们引导团队，也感到有信心我可以以可能会坚持的方式帮助解决冲突和做出决策。他们中的许多人也在自己的团队中重复了这些模式。但确保我的领导感到有权力绝对是我一直关注的重点。

3.2 实现技巧

作为生产力技巧的学生，我花了很多时间开发技巧来帮助这些过程运作。一些建议：

为你的日历上色：一旦你为会议制定了分类，为每种类型的会议分配一种颜色，并让你的管理员相应地进行上色。这样你就可以一目了然地看到你这一周的感觉。
为每次会议写下你的单一目标：我用一个特殊的电子表格宏实现了这一点，它给我提供了一个表格，每周每次会议都有一行，我会逐一写下我希望在会议中完成的一件事。这非常清晰。如果我想不出一个目标，我通常会尝试取消会议。如果这是一个我认为团队可能没有准备好的目标，那就提醒我给他们发个通知，以便他们可以准备。
共享笔记/目标：每次与固定听众（尤其是 Tag-Ups 和 1 对 1 会议）的会议都需要一个共享的 Google 文档，里面有笔记和下次会议的议程项目部分。我让我的电子表格宏将其导入到我的中央日程表中，以便我可以查看团队的计划，添加/删除该列表中的内容，并与我“该会议的一个目标”进行同步。
会议审计以审查和减少会议时间分配：我们保持更新的 YT 会议彩色表格地图让我始终知道我在每种会议上花费了多少时间。如果我发现自己在 Tag Ups 上花费的时间过多，我就有一个明确的地方可以缩减。
打印你的预读：有些人更喜欢在电脑上阅读，但我对打印出来的阅读上瘾了。我们尽量不浪费纸张——我的管理员会将它们每面打印 4 页（4-up）并双面打印，这样我们就能在一页上放下 8 页阅读。这有几个好处：

这给了团队一个真正的截止日期 – 每个人都知道我会阅读打印件，所以他们会问我的管理员我是否已经打印了。
它让我能够集中注意力——当我在电脑上阅读时，我往往会分心，而这帮助我集中精力。
这仍然是以一种便于稍后快速综合的方式记录想法和笔记的最佳方法。

一致的个人日程：如果你想努力不重新安排会议并保持固定的节奏，那么拥有一致的个人日程会有所帮助。按时上班和下班等等。对我帮助很大的一点是，我承诺从回家到孩子上床睡觉期间不打开我的笔记本电脑。这合理地分割了我的一天，并让我在他们上床后花时间为第二天做准备。

3.3 投资于你的行政人员和/或你的幕僚长

很少有事情能比拥有合适的管理员和幕僚长更能提升力量倍增器。

对于你的管理员：他们有很多方法可以帮助加强这些流程。给你的日历上色，确认你为每次会议设定了目标，打印预读材料等等。此外，我发现明确授权我的管理员成为我的情商监督者也很有用——也就是说，她会告诉我如果有人感到不满、被忽视等——这些在结构化评审中很难弄清楚的事情。.

为你的幕僚长:

首先要仔细选择。我非常相信这应该是一个兼职工作（即在你们组织内有日常工作的某人）。这让他们保持相关性/参与感，但最重要的是，它可以防止经典的不良选择——选择一个在你们组织中已经不成功的幕僚长。
我通常将这份工作分为三个部分：（1）运行组织流程（例如每周的节奏、H1/H2 规划等），（2）处理沟通（为我起草演讲稿、广播邮件和演示文稿），以及（3）充当我的替身。
第三个是最难的。我使用的一个策略是，我会让我的幕僚长把我这一周的任务清单拿过来，完全把其中一项任务从我的清单上移除，转到他们的清单上。