一些工程师形成了一种强烈的观点，认为开会是在浪费他们的时间。这种观点有充分的理由，因为许多会议都非常糟糕，但它也有点短视：会议也可以成为一个运作良好的组织中非常有价值的部分。如果您收到的反馈表明任何给定的会议都没有帮助，请对其进行迭代，并考虑暂时暂停它。它可能对您的组织还没有用，但不要放弃开会的想法。
好的会议是您组织的心跳。
如果你仔细观察，你会发现少数例外，但绝大多数运作良好的组织都围绕着一些有价值的会议，它们也可能是你组织的最佳起点。 （顺便说一句，如果你想再读一读关于会议的精彩内容，我强烈推荐史蒂文·辛诺夫斯基的，非常好。）
为什么要开会？
组织内最有效的沟通发生在同事之间或经理与其直属团队之间。您的技术战略最好以书面文件的形式传达。最清晰的计划在工单跟踪器或文档中进行跟踪。这些理想的方法都不是大型会议，这并不奇怪：大型会议很少是实现任何特定目标的最佳沟通解决方案。但是，当您的默认方法存在差距时，它们是非常有效的备份解决方案。
在一定规模下，您无法与组织的每个成员讨论所有事情，但您可以让每个经理与他们的团队交谈，并通过组织范围的会议来补充。您不能在每个技术决策的早期就包含每个人的意见，但您可以通过在技术规范审查中分享这些决策来确保这些决策得到很好的审查。虽然会议很少是最好的初始解决方案，但它们通常是确保重要信息在整个组织内沟通的最佳备份解决方案。
虽然大多数领导者将组织会议视为向下报告层级分发上下文的必要机制，但我发现它们在其他两项重要任务中也很有效：沟通文化和表达组织的担忧。要在您的组织内实现所有三个目标，可能需要根据其规模、沟通规范和全公司会议来定制工程会议组合。
也就是说，我想推荐六个核心会议，我建议每个组织都从这些会议开始，而且我发现它们可以走很长的路。这六个会议分为三个运营会议（每个经理与其直属团队、技术规范审查、事件审查）、两个发展会议（员工工程师、工程经理）和最后的每月工程问答，以了解组织的真正想法。
每周团队会议
一个关键角色是让团队一起朝着相同的目标前进——现在什么才是真正重要的？另一个是设定团队的节奏——我们这周做了什么？最好通过为您的直接下属和主要利益相关者团队召开每周工作会议来完成这两项工作。
工程领导会议，以及 CEO 与公司领导团队召开的类似会议，是您运营工程组织的核心枢纽。首先，这次会议是您的领导团队共同完成任务的工作会议。如果有什么事情需要解决（战略上的分歧、关于新职业阶梯的冲突等），请使用此会话来解决它。
其次，这是您的团队彼此分享背景的机会，而不仅仅是与您分享。本周对他们来说什么是对的或错的？他们的同龄人如何帮助他们完成当前的项目？意外发现始于整个团队的相互了解。
最后，这是您的论坛，可以将您的指挥打造为首要任务是相互支持的第一支球队。 （如果您还没有读过 Patrick Lencioni 的《团队的五种功能障碍》 ，这是关于这个主题的快速而精彩的读物。）
使您的团队会议有效的一些建议：
- 我的每周团队会议总是包括我的直接下属，通常包括我们在招聘、人员和财务团队中的主要合作伙伴。 （我也尝试过让工程师参与进来，这是一个建设性的尝试，尽管是混合的实验！）让跨职能的合作伙伴在房间里建立跨职能的信任，并且通常会让你立即解决问题，而不是把它们放在待办事项清单上稍后解决
- 在可组编辑的文档中维护正在运行的议程，团队中的任何人都可以在一周内添加议程主题。在会议开始前花几分钟确定即将举行的会议的主题优先顺序
- 我会强烈推动核心工程领导团队每周开会。我只会在非常小的公司（<20 名工程师）或发展缓慢的企业（每月变化不大）减少频率
无论您决定召开每周团队会议，请记住您的直接下属可能会以您的会议为榜样。如果你召开了一个紧凑、有效的会议，那么你的整个组织很可能会召开同样有效的团队会议。
技术规范审查和事件审查
技术规范审查和事件审查是每周一次的会议，讨论自上周以来的任何新的技术规范或事件。在平静的一周，这两个会议都可能被取消，但在美好的一周，两者都将以截然不同的方式推动公司前进。
每家公司都将举办这些会议的不同版本，并且会议本身会随着时间的推移而发生一些变化。针对我所见的一些建议可以促成有效的复习会议：
- 所有评论都应以简洁明了的书面文件为基础
- 阅读书面文件应该是提供反馈的先决条件。一些团队发现从十分钟开始阅读文档会很有帮助。或者，在工程日历的审查会议之前预留三十分钟以进行独立阅读可能会有所帮助
- 好的评论基于观众的反馈，以及作者和观众之间的讨论。不好的评论是基于作者展示他们的文档。如果您努力引导人们远离展示他们的文章，您只会获得好评
- 应该有一个清楚记录的、非常简单的过程来安排你的事件报告或技术规范。我见过的更有效的方法是在 Slack 中要求将专用房间添加到日程表中
- 从长远来看，您可以通过人们是否提交新技术规范和事件以供审查来衡量这些审查会议的影响。如果论坛难以征集内容，这通常表明您应该努力使它们对与会者更有用
- 与经验丰富的演讲者一起练习，让初次演讲者做好准备！这将使他们更有信心，促进更有价值的讨论，并避免花费数千小时聆听那些错误地认为审查应该是他们大声朗读文档的人
- 进行这些审查非常耗时，我强烈建议为每次会议寻找专门的负责人。虽然有时有点烦人，但两者都是非常有影响力的领导机会，可以由经验丰富的工程师运营
许多工程领导者在忙碌时会跳过这些评论——当你在任何一个论坛中声音最大时，这肯定是一个不好的迹象——但它们是重要的论坛。他们是难得的机会看到许多团队的工程师和广泛的资历在相对高风险的话题上进行互动。这使这些会议成为您工程文化的清晰晴雨表。如果你对自己公司的这些会议感到不舒服、无聊和沮丧，那就解决它。
工程经理和高级工程师月刊
我每月召开两次会议，重点关注持续的团队发展。第一个是工程经理月刊，所有工程经理都参加，第二个是员工工程师月刊，所有员工加工程师都参加。在大多数组织中，这些组处于相同的数量级，并且在所有组织中，它们对于运行良好的工程组织同样重要。
每个会话的格式略有不同，但通常是这样的：
- [15 分钟] 让每个成员花 1 分钟时间分享他们正在做的事情，让他们兴奋的事情，以及让他们担心的事情
- [30 分钟] 有人，通常是我，介绍了一个发展主题。这些可以是为团队创造机会发展其专业技能的任何事物。对于经理会议，它可能是我最近读到的一些东西，比如 Lara Hogan 的一篇关于授权的文章，或者是我写过的一些东西，比如阅读损益表。对于 Staff Engineers 会议，它可能是 Tanya Reilly 的The Staff Engineer’s Path或我自己的Staff Engineer的主题
- [15 分钟] 以开放式问答结束
如果有紧迫的话题——最近的重组或类似的话题——那么我们当然会专注于此，但我认为支持团队的个人发展很有价值。做得好，他们会让每次会议对团队更有价值，并且更有信心公司投资于他们的成功。
工程问答
我推荐的最后一个会议是工程问答会议。我每月运行一个小时，从介绍新团队成员开始，然后花几分钟分享我希望团队考虑的任何信息。然后我们进入问答环节以进行剩余的会议。如果我们的问题用完了，我们就会提前结束，但我发现这种情况很少发生。
许多工程师不会直接与您合作，他们会根据您在这些问答中如何回答最困难的问题来学习信任（或不信任）您。同样，您可能不会在任何其他论坛上听到他们的担忧。这些担忧应该会通过报告层级向上级传递给你，但有时会出现沟通障碍，这是信息跨越鸿沟到达你手中的一种方式。
进行良好的问答取决于不断地从听众那里得到好的问题。我发现有一些技术对此很有价值：
- 我在每次问答开始时都会说，“我很高兴谈论任何事情，没有问题是禁止的。如果你的问题太尴尬或太私密，我会避免回答。想问什么就问什么。”这在一定程度上是个玩笑，但这也是我主持会议的方式。有时人们会提出愤怒的问题。有时他们会问一些已经通过电子邮件回答的问题。我总是试图带来一种均匀的、积极的能量，即使问题很乱
- 拥有一个好的提问工具大有帮助。我推荐三个核心功能：在会议开始前提问的能力、投票决定哪些问题最重要要回答的能力以及对匿名问题的支持。我总是更喜欢困难的匿名问题，而不是那些因为太不舒服而不敢问的人，即使这会导致尴尬的会议
- 在 Q&A 即将到来的前一天和一小时提醒人们，并引导他们使用 Q&A 工具，以最大限度地增加收到的问题，尤其是提问者
- 以问答为契机，重点介绍从事重要工作的个人或组织中的主要领导者。当一个问题涉及到某人的工作时，我会警告他们我会在将问题传递给他们之前快速分享我的想法，给他们几分钟时间准备，分享我的想法，然后再传递给他们
- 每个组织都有一小部分人忍不住要问问题。培养这些人，以确保您至少得到一些问题！良好的工具（问题投票工具）或卫生（即使举手时也能暂停，让其他人也可以提问）将减轻仅回答他们问题的潜在不利影响
- 如果您的团队的时区窗口相对较窄（大约相差三个小时），那么您可以找到适合所有人的固定时间。但是，如果您的 timezome 窗口更大，请考虑在几个时间段之间交替时间，以确保每个人都能够轻松参加至少每隔一次的问答。我通常建议跨时区分散会话而不是增加频率。我通常也建议不要录制问答，因为问题质量往往会下降。也就是说，这里的实验很便宜，所以如果您认为它们会更好，请尝试不同的选择
虽然您可能不会立即同意，但工程问答通常是我本月最喜欢的会议。这是我了解我相对于我的团队和组织的期望表现如何的地方。事情进展顺利吗？团队是否对某事感到不安？这是我已经知道的问题吗？我可以修复它以防止他们下个月为此烦恼吗？如果您不相信，请尝试几个月，然后从那里开始。
其他会议呢？
除了我上面建议的会议之外，许多组织还举行会议，这是完全合理的。我还举办了其他一些会议，我发现这些会议非常有帮助，从与新员工会面的每周会议到我们庆祝发布并讨论即将到来的挑战的季度工程全体会议。重点介绍一些许多公司认为有用的会议：
-
执行会议：您绝对需要某种每周或每月的执行审查会议，以跟踪和调试执行情况。这次会议的名称因公司而异，从业务审查到运营登记再到计划审查。
我的经验是，这次会议需要跨职能而不是特定于工程。任何特定职能的执行审查都可能将责任分配给不在房间内的其他职能，而跨职能审查更有可能解决问题
-
展示和讲述/演示：是一种文化形成会议，让与会者清楚公司庆祝哪些工作。这些通常是一次特别愉快的会议，以人们分享他们引以为豪的事情为中心。不同公司的频率从每周到每月略有不同
-
Tech Talks / Lunch & Learn ：是团队成员一起学习的机会，可以通过教授专业领域，或者一起阅读书籍和论文
-
全员工程：你确实希望工程师们花时间在一起，但你想怎么做会因阶段和其他公司会议而有很大差异。另一个问题是全体会议有点不限成员名额。你的全员大会真的是一场表演和讲述吗？还是路线图审查？或者完全是别的东西？
我的经验是，这些额外的会议中的大多数在很大程度上取决于您更广泛的公司会议日历。例如，您的公司是否已经有每月一次的全体会议，您在那里谈论什么？当你已经有每月一次的公司全员大会时，每月举行一次全员工程大会通常很难协调，你必须自己决定。我更喜欢尽可能与现有的公司会议保持一致。对于工程师来说，了解其他工程师在做什么很重要，但了解其他职能部门的人员关注的重点对他们来说更有价值。
谁主持会议？
作为工程主管，您通常会主持团队会议、经理和员工工程师月刊以及工程问答。你也可以领导技术规范审查和事件审查，但随着你的组织的发展，你的直接下属或一名主管工程师可能会领导这些论坛（因为他们需要一定程度的持续关注，这可能难以维持作为一名专注于灭火的高管）。如果你引入更多的会议，比如展示和讲述，那么由谁来主持会有很大的不同。
这里要考虑的三个要点是：
- 主持会议并不一定意味着您需要进行协调工作才能使其取得成功。您通常会在这些方面与执行助理或项目经理合作
- 团队将密切关注您并从您的行为中获取线索。即使你说会议很重要，只有你经常出现，他们才会相信你。如果你不参加，其他人很难领导组织会议
- 即使您不领导或协调这些论坛中的一个或多个，您也有责任充分利用组织的时间。那是你不能委托的事情。
与所有事情一样，对于跨组织谁做什么没有明确的规定。如果您想尝试不同的东西，请尝试一下。
扩展会议
许多组织的会议都比这多，这完全没问题。做适合你的事。同样，一个拥有五名工程师的组织只需要其中一次会议，即与他们的直接团队的每周会议。缩小规模相对容易——取消没有帮助的会议——但扩大规模可能会有点混乱。
一般来说，我会推荐：
- 扩展运营会议以针对合适的参与者进行优化。如果您的技术规范审查会议偏向于移动问题，但大多数与会者不了解移动设备的背景，那么您可能希望分开一个专门的移动会议
- 扩展发展会议以优化参与者的参与度。如果你有超过 10 个人参加发展会议，他们中的许多人将停止参与甚至停止参加。如果您有 20 多个工程经理，请考虑将此会议向下推到报告层次结构的下一层，这样您的报告就可以与他们的经理召开他们自己的开发会议，而不是您与整个组织召开会议。 （当然，你可以找到混合的方法！你可以每隔一段时间开一次会。你可以在介绍内容等之后集中精力分成小的讨论组。）
- 我建议将 Eng Q&A 作为整个组织的事务，但你绝对可以考虑让你的直属推出他们自己的 Q&A 以及一定规模（例如，一个拥有 600 名工程师的工程组织当然可以容忍 Eng Q&A 和 Product Eng每月问答）
最后，我发现许多组织过早地拆分会议是因为有一两个人在重要会议上表现不佳。例如，您可能有一个敌对的工程师，他参加每次技术规范审查会议来倡导特定技术。通过让工程师对更高的通信标准负责来解决这个问题是非常有价值的。如果不让参与者对自己的行为负责，就无法扩大大型会议的规模。
1:1 和跳级
为了完整起见，我还强烈建议每周与您的直接下属和与您合作最密切的同事进行 1:1 的交流。借鉴我在 Calm 的具体经验，在第一年里，我每周与三位高管同事会面，而其他同事每月一次，每次一小时。我与我的团队的每个成员会面了一个小时，虽然我们已经一起工作了几年，但有几周那些 1:1 的会议恰好是 30 分钟的会议。
与您的组织的越级会议也非常有价值，尽管我发现随着您的组织的发展，很难为它们创造空间。我的建议是确定固定的时间用于跳级，比如每周一到两个小时，并迭代频率和格式以保持在该分配范围内（进行小组跳级会议，而不是每季度开一次会）每月一次等）。跳级感觉很有成效，如果你不经常这样做，你可能会感觉很糟糕，但不要让它们妨碍你执行核心工作。
会议不是孤立的
最后，一些结束语。首先，重要的是要指出您不能仅通过会议在组织内建立有效的沟通。良好的沟通包括会议，但需要牢固的个人关系并通过许多其他渠道（电子邮件、聊天等）进行工作。
其次，您应该将您的会议方法与更广泛的公司方法相结合。在某些情况下，您会发现其中许多会议已经存在，并且您希望与这些现有论坛集成而不是创建重复的论坛。在其他情况下，您甚至可能会发现在工程部门甚至工程部门的一个子集内运行这些程序可能是一种有效的方式，可以让人们意识到他们是在很好地利用时间。