通过界面管理团队

转变为管理经理，从而管理许多团队，可能会给大脑带来沉重的负担。如果你以前没有这样做过，那么你可能会看看其他担任更高职位的人，他们可能管理着数百人的组织，你自己可能会想，他们是如何找到时间或精神时间来完成任何事情的。

如果你习惯于管理一个团队，这是一个合理的想法。毕竟，管理团队是一项艰巨的工作。这包括在管理他人和做出自己的贡献之间平衡时间，与团队以外的人合作，深入了解员工的个性和愿望，当然，我们不要忘记最重要的事情：发货软件。

通过这个镜头来看，拥有多支球队的想法可能看起来相当压倒性。你怎么能把你以前做过的每件事都放在你的脑海里，但要用很多倍的比例呢？嗯，答案是你不应该这么做。这就是为什么你有经理向你汇报的原因，这允许你在更高的抽象水平上工作。

在这个更高的抽象级别上工作可以让您将精力集中在重要的事情上；无论这种重要性是体现在工作流的操作运行中，还是体现在对未来的战略规划上。它允许你后退一步，把你的精力集中在它能带来最大红利的地方：即使不是数百人，也是几十人的产出。

因为阅读本网站的读者通常都有编写软件的背景，所以我将使用一个软件工程类比来解释您是如何利用您的经理在这个更高的抽象层次上工作的。我们将通过查看，呃，接口来查看您和您的经理之间的接口。真方便啊。

我最有经验的编程语言是Java，所以我将依靠它来进行这个特殊的类比。Java中的接口与其他语言中的接口一样，是一种允许您定义抽象方法的类型，如果其他类实现该接口，则这些方法必须具有这些抽象方法。

公共类BritishCurseGenerator实现CurseGenerator{public string curse(){return“哦，该死的！”；}}。

接口允许软件系统中的可扩展性，因为特定的代码段可以与实现给定接口的任何类一起工作，因为在编译时会检查接口的方法是否存在于实现类中。

最重要的是，使用接口的代码不需要知道实现的细节。实现类可以做任何它想做的事情，只要它遵守方法签名的约定。该接口将实现委托给实现类。

你明白这是怎么回事了吗？我相信你会的。回到管理方面的类比：

作为经理的经理，您定义代表每个团队的界面是什么样子。例如，您可以定义重要的特定度量，如应用程序正常运行时间、每日活动用户等KPI。您还可以要求您的经理每周与每位员工举行一对一的会议，每两周向公司其他部门撰写一份进度报告，或者在一个工作日内修复关键的优先级错误。

只要他们遵守接口合同，您的每个经理都可以灵活地准确决定这些团队是如何运行的。因此，他们决定如何解决提高正常运行时间百分比或日活跃用户数量的问题完全取决于他们。哪些成员负责代码库的哪个部分取决于他们和团队。他们如何以及何时安排他们的一对一，他们讨论的内容由他们决定。但从根本上说，它们应该遵守接口的约定。

清晰的界面使您不必担心每个经理如何管理其团队的具体实现细节，但它们允许您明确您在这样做时对每个经理的期望，从而明确您如何定义成功。好了，我现在停止编程类比。

因此，您可以从定义与每个经理的接口开始。你们的第一次一对一会议有一个很好的练习(尽管你可以在任何时候做)，叫做签约，我以前写过。您可以通过让您双方思考以下问题的答案来扩展合同练习，这些问题构成了界面：

团队的成功是什么样子的。用什么衡量标准来证明团队是成功的？它是在努力实现一个结果，还是一些关键绩效指标，或者按时交付特定的项目？它是否也考虑到员工的幸福感、生产力和心理安全感？如何收集这些信息并使您可以访问这些信息？

将使用哪些流程来运行团队。为了成功，他们将如何镇定自己呢？他们会使用Scrum、看板、继续做下去，还是其他什么？他们打算如何定期发货到生产呢？他们将如何确定工作的优先顺序和如何执行？你的每个团队可能会根据每个团队成员的技能和资历而有所不同。

经理如何与自己的每个员工打交道。他们需要考虑每个员工的不同个性、技能和职业发展轨迹，并考虑这对他们每个人如何能够自主、掌握和有目标地运作意味着什么。对于一对一来说，什么是可以接受的节奏？他们更喜欢同步通信还是异步通信？

如果有什么地方出了问题，你怎么知道呢？代码引发错误或执行缓慢，从而引起您的注意。如何让团队的问题变得可见，以便你们可以共同解决这些问题？

您是否愿意偶尔亲自检查一下实现情况。尽管定义接口的目的是对您隐藏复杂性，但偶尔查看一下内部情况并了解那里发生了什么是很有趣的。你可能会有一些建议让它变得更好，或者你甚至可能会学到一些新的东西。你可以安排跳级会议的节奏，偶尔出现在他们的小组会议上倾听，并从个人和整个团队获得反馈。

只要事先在界面上做一些工作，你就可以绝对清楚地表明，在你们的关系中，你们两人对多大程度的参与都感到舒服。这允许您从作为经理的经理不需要了解的问题中抽象出来，并使您的直接下属可以自由地按照他们想要的方式来管理团队，只要您期望的基本原则正在实施。这很棒，因为你可以在这个基础上建立良好的教练关系，而不是面临微观管理或解雇和遗忘的风险。

有时事情会出错，就像它们在代码中所做的那样。您可能需要把调试器拿出来看看发生了什么。但是没关系，因为您已经讨论了您、您的直接下属和他们的团队之间的接口。该接口为您提供了许多方法来附加调试器。

也许如果团队的节奏变慢了，您可以更深入地挖掘用于运行团队的流程。他们多久发货一次？如果这不是很常见，为什么会这样呢？如何编写、审查和部署代码？您可以不断询问原因，以便弄清可能是错误的怪癖。然后你就可以把它们修好了。

有时纯粹出于好奇而附加调试器是很有趣的。您可以在与直接下属的一对一交流中做到这一点。专注于界面的一个区域，通过提问深入到实现中。您总能找到一些值得讨论的东西，而且通常会有一些巧妙的性能优化可供尝试。

理想的结束状态是，你和向你汇报工作的经理之间有明确的期望和界限。当您明确了每个经理应该执行哪些高级功能后，您可以将实现委托给他们，这样他们就可以以他们认为对他们和他们的团队最有利的任何方式来实现。

这使您可以远离不需要花时间关注的细节，从而使您能够在更高的抽象级别上工作。如果您正在编程，这种抽象将允许您专注于使围绕接口的系统更高效、更可扩展、更高性能和更优雅。这正是你在团队的组织、结构和战略方向上想要做的。