没有国王:你如何在平面组织中有效地做出良好的决定?

后端团队领先的实用思想

国王的决策大致一致
插图的尹卫生
本文始于在我们的团队如何学会询问和向反馈的内线上进行内部对话。它探讨了我们如何快速平衡决策,同时保持我们的开放性,以确保我们的决定是好的。

Doist我们认为,开放和真诚的沟通改善了我们的决策过程。这就是为什么我们建立了一种鼓励各级决策的反馈的文化:从纯粹的技术解决方案到团队和产品管理。我们建立了我们的团队通信应用程序,为我们自己和其他偏远的工作场所提供这样的透明度和参与。乐动捕鱼达人

最初,我们认为您获得的输入越多,您的决定越好。(此想法与工程精神自然相当地对齐,更多的数据意味着更好的决定)。

然而,随着我们团队的成长,我们认识到,好事太多不是好事。我曾经看到我们的一名设计师向团队询问关于Twist标志的草稿的反馈。突然之间,所有人都变成了字体和标识专家(我也感到内疚),并向他提供了大量反馈。

最初,我们认为您获得的输入越多,您的决定越好。

作为Doist后端团队的领导者,我认为这种反馈过载是对我们团队高效运作能力的巨大挑战。投入太多了。越来越多的时间花在回应反馈上,而不是执行决策上。就在那时,我看到了一份详细说明“大致共识”原则的文件。

粗略的共识

互联网工程工作组(IETF)是一名基于会员资格的设计师,运营商,供应商和研究人员,这些研究人员开发了将互联网塑造到我们今天使用的工具中的标准。他们在1992年由Dave Clark创造了他们的主要决策原则:

我们拒绝:国王、总统和投票。

我们相信:粗略的共识和运行代码。

我一直很好奇“粗略共识”是什么意思。你怎么知道你已经达到了一个?

一群人如何在没有明显正确答案的情况下没有“国王”的情况下做出最好的决定?

事实证明,有一份文件详细解释了IETF决策方法背后的过程和意识形态,名为“RFC 7282。IETF中的共识与哼唱。“它提供了关于如何提前技术讨论的非常实用的指导方针,以围绕解决解决方案而没有不必要的延迟。本文件对我们所有人都有所帮助,尤其是产品领导和队领导者。

IETF面临同样的挑战,所有技术团队都在塑造产品并指定其组件的行为。随着文件所说:

“工程总是涉及一系列权衡。几乎可以肯定需要进行任何时间工程选择,会有一些人吸引一些人,但并没有吸引其他人。“

问题变成了:在没有明显正确答案的情况下,一群人如何在没有“国王”的情况下做出最好的决定?对如何做出决策有共同的理解是必要的。

投票通过的嗡嗡声

在IETF中,当他们需要投票时,他们有时会哼哼而不是举手。这样做的目的是为了让投票更加匿名,同时也为了抵制仅仅根据票数来做决定的诱惑。正如文件中强调的那样,哼歌给了人决定“测量房间温度”的机会。这只是他们用来推动讨论向前发展而不是结束讨论的一个工具。

While this approach can’t be replicated exactly on a remote team for obvious reasons, it does illustrate some of the main principles behind rough consensus and what distinguishes it from top-down decision-making on the one hand and majority-rule decision-making on the other.

“不是最好的选择”与基本缺陷反馈

粗略的共识依赖于两种反对意见的区别:

  1. “不是最好的选择”反馈:“我不相信解决方案A是最好的选择,因为XYZ。我相信解决方案B会更好,但我接受解决方案A也可以工作。“
  2. 基本缺陷:“我相信解决方案A是不可接受的,因为XYZ。”

粗略的共识不是多数决定原则。如果一个解决方案看起来对每个人甚至大多数人都不是最好的选择,那也没关系。“不是最好的选择”意味着你相信有更好的方法来解决问题,但你接受这个方法也会起作用。这种类型的反馈应该受到欢迎,但不应该被允许延缓决策。

一旦每个人都可以与给定的解决方案一起生活,即使有未突出的反对意见,您也达到了粗略的共识。

另一方面,在讨论完成之前,这对解决并讨论所有基本缺陷至关重要。基本缺陷是应对提出的解决方案取消资格的重要问题。难以定义有资格作为基础缺陷的内容,但几个出发点是:

  • 它将大大提高技术债务。
  • 它伸缩性不好(除非特定环境不需要可伸缩性)。
  • 它需要太多的工作来实现,并且它不能证明解决方案所增加的价值。

这个列表并不完整,其他团队当然会以不同的方式定义一个基本缺陷。例如,基于我们尊重用户的时间、注意力和意图的价值观,产品设计团队可能会认为任何不必要地分散用户注意力的解决方案都存在根本性的缺陷。基于我们公司保持独立和可持续发展的优先考虑,营销团队可能会认为任何成本超过收益的解决方案都是有根本性缺陷的。

对于一个组织来说,对于什么是“根本有缺陷的”,就提议的解决方案进行讨论有一个共同的理解是很重要的,即使这个定义随着时间的推移而发展。

要求输入的艺术

您如何确保完全解决基本缺陷而不会扼杀或通过非关键反馈减慢速度?以下是在讨论停滞不前时,IETF如何建议在粗略的共识:

一个询问的椅子,“每个人都可以选择a?”会变得反感。但是一个询问的椅子,“任何人都没有选择一个?”更有可能只听到人们认为选择A不可能为某些限制而无法设计。对象可能会说服剩下的小组,反对意见是有效的,工作组可能选择不同的路径。

正如你所看到的,反对者不能简单地说“我不喜欢解决方案A”,甚至不能通过提供一个他们认为更好的替代方案来反对——他们必须首先证明为什么解决方案A有根本性的缺陷。

一旦每个人都可以与给定的解决方案一起生活,即使有未突出的反对意见,您也达到了粗略的共识。

关于妥协

IETF文档的很大一部分致力于折衷的问题,区分了两种类型:

遗憾的是,“妥协”一词以两种不同的方式使用[...]工程始终涉及平衡权衡[...]:我们可能必须损害处理器速度,以降低功耗,或损害吞吐量的吞吐量。这些妥协是工程选择的,它们是预期的,并且是必不可少的。[...]。

然而,“妥协”还有另一种含义,它涉及人与人之间的妥协,而不是工程原则。例如,一个群体中的少数人可能会反对一个特定的提议,甚至在讨论之后仍然认为这个提议是非常有问题的,但他们决定没有精力去反驳它,并说,“算了,做你想做的”。这当然可以称为一种妥协[……],但实际上他们所做的一切都是屈服。这还没有达成共识;仍然存在一个未处理的反对意见。

再次,如果异议只是选择不理想,而是可以接受,这种妥协是好的。但是,当有一个真正的出色的技术异议时,不达成共识。

有时有一个诱惑跳进扭曲线程,并在持续的讨论中添加一个快速的“两美分”。有机会是,这两美分将是一种真正的真实性,可能不值得分享,这是一个需要进一步解释的最初或意见,以完全证明。

如果不值得花时间去过多地传达你的观点,那么反馈就不值得拖延讨论。

在后一种情况下,决策者可能会忽略你的反馈,因为他们并没有完全理解你的反馈,或者不得不继续跟进,以找到你反对的根源。尽你所能给他们提供他们需要的信息来预先评估你的论点。如果你认为你的反馈很重要,那就说出来,花额外的时间从一开始就解释和捍卫你的立场。

这在远程团队中尤其重要。在这里,我们缺乏快速的来回沟通来阐明要点,而且一个人的两分意见会严重减缓决策过程。

如果不值得花时间去过多地传达你的观点,那么反馈就不值得拖延讨论。

粗略的共识并不矛盾,我们宣讲的完美主义?

粗略的共识方法与我们在招聘时采用的“如果不是‘当然’,那就是‘不’”的标准形成对比(也就是说,除非每个人都很赞同,否则拒绝一位候选人)。然而,我认为,对于我们面临的大多数技术和产品相关的挑战,较低的决策标准是可以接受的,甚至是必要的。

我们可以使用“地狱”原则来招聘和其他一些决定,但我们在运送事物时使用快速迭代原则。我们第一次瞄准完美 - 我们建立快速,我们发货,我们学习,我们迭代,我们再次发货。一步一步,我们到达我们想要的地方。如果我们向我们发货的东西申请了完美的标准和完全共识,我们很快就会变得缓慢。

当我们为了达成完全的共识而推迟决定时,我们的风险更大。

多亏了我们“当然”的招聘方式,我们可以相信做出决定的人的能力和勤奋。是的,在粗略的共识下,我们可能不会做出最好的选择,但如果决策者认为这是最好的解决方案,我们可以相信它是足够的。

即使结果证明这不是最好的决定,最终,我们能够提高的操作速度,平均来说,将弥补挫折。当我们为了达成完全的共识而推迟决定时,我们的风险更大。

粗略的共识并不意味着我们在解决方案的实际执行中不追求完美。在实施时,我们应该始终以技术卓越为目标。对实现的承诺通常是使解决方案成为正确方案的关键。(这与亚马逊的“不同意和承诺”哲学类似。)

我们可以从IETF的大致共识中学到什么(也就是为什么要共享所有这些)

IETF案例是一个很好的例子,说明了具有不同结构和文化的组织如何解决决策的普遍问题。

我并不提议我们向我们所有的决定申请粗略的共识。我们不是IETF - 我们的目标和结构是完全不同的。但是,我相信我们可以从他们的经验中吸取宝贵的课程。

如果有一个足够好的X解,不要问别人怎么想。相反,问问每个人是否能忍受,如果不能,为什么。

我们的目标是保持一个相对平坦,透明和包容性的组织。因此,基于共识的决策,而不是自上而下的决策。我们如何利用集体投入的好处,同时快速制定决策?

粗略的共识是确保小调或非关键问题不妨碍我们的表现的良好标准,并且在我们的腰带中是一个有效的工具,因为越来越多的声音被添加到团队中。

以下是一些混凝土外卖,我们都可以申请更高效和更有效的决策:

如果您是一个对解决方案的反对意见:

  • 在您对象之前,请衡量您的异议是否揭示了一个严重的问题。这是可以说的“我相信有更好的决定,这是如此,但我也可以对当前的选择也没问题。”建议改善想法(或实施,如果您讨论了示例的拉动请求)也可以改进,而不否则当前选择。明确您提高的异议类型。
  • 如果您认为选择具有阻止的漏洞,请尽可能清楚地使您的反馈表明,以便决策者可以正确地解决。
  • 如果您认为选择有一个封锁缺陷,请尝试找到足够的时间和精力来说服对手。当您区分非关键反馈和基本缺陷并优先考虑后者时,您可以保护最重要的讨论的时间和心理能量。

如果你是一个决定:

  • 保持警惕并确保讨论不会在非关键方面停滞“不是最佳解决方案”反馈。
  • 如果讨论不能集中起来,请与会者澄清对提案的反对是否涉及应予以考虑的根本缺陷或意见。
  • 如果有一个足够好的X解,不要问别人怎么想。相反,问问每个人是否能忍受,如果不能,为什么。
  • 不要觉得你必须服从多数决定原则。

共识是道路,而不是终点

IETF文档中的最后一句话:

我们并不试图在IETF中达成共识作为目的本身。当我们做决定时,我们把建立共识作为一种工具来获得最好的技术(有时是程序)结果。

在Doist,我们努力创造一种文化,让每个人的反馈都能被听到。我们相信我们是一家更强大的公司。但正如我们所知,这需要讨论各方的努力和自我意识。虽然我们还没有做到这一点,但是粗略共识的原则对于平衡我们所有决策的反馈和效率是很有用的。

决策的僵局会使项目停滞不前,拖延进程。我们的在线手册,远程项目101:远程项目管理指南,介绍了如何解决分布式团队中跨功能项目的常见问题。