Joe Duffy's Software Leadership Series

一方面，架构师是项目中最重要的首席工程师。另一方面，架构师更像是项目董事会的成员，提供高层指导并尽可能少地（但尽可能多地）干预日常细节。

架构师的成功取决于他或她向客户交付的产品，而不是最终从未实现的惊人想法。这必然意味着架构师的成功深深植根于团队的文化、职业道德和能力。他或她需要通过他人来完成工作。

---

架构师最终的成败取决于团队成员的素质。因此，知道如何激励和授权这些人，使他们能够做到最好，是建筑师要想取得成功所需要的最重要的技能之一。

你不能自己做这一切。这有时会令人沮丧，有时你可能认为你可以（尤其是在沮丧的时候）。我亲自将 1,000 行代码拼凑在一起，我在一个周末感到无比自豪，如果我不得不向其他人解释这个想法并等待他们解释，那将需要数周或数月才能完成编写相同的 1,000 行代码。当然，他们写的 1,000 行最终不会和你写的一样。他们可能会决定他们根本不喜欢这个设计，开始与同事讨论它，发动叛变，并最终推翻曾经看起来很棒的想法。这是一颗难以下咽的药丸。但这是生活中一个可悲的事实，您需要学会接受它。

我并不是建议架构师不要编写代码（恰恰相反：请参阅下面的#3），但您不能全部编写（非常小的项目除外）。如果您相信架构师只是项目的主要高级工程师这一论点，那么根据定义架构师可能有资格快速编写高质量的代码。但是他们不写的代码呢？团队中的其他人需要编写它，而架构师需要有足够的时间（他或她没有破解代码）来激励这些人编写正确的代码。这需要精力和努力。你需要描绘一幅引人注目的未来图景，但要有足够的开放性，这样团队才能发挥他们的创造力并填补细节。

---

建筑师还应该张开双臂欢迎所有想法。你想在你的团队中培养一个开放和充满活力的环境，在这个环境中，智力辩论是常态。所有的想法都是公平的游戏。

---

因为架构师的屁股最终是在线的，所以当出现问题时，他或她需要尽快工作以纠正问题。这意味着架构师的参与足以在出现问题时注意到，希望在其他人看到它之前就很好。我见过许多行之有效的模型，从架构师作为所有主要设计决策的批准者，到架构师仅在事后审查所有主要设计决策，再到架构师将此责任委托给可信赖的顾问。例如，Linus Torvalds 最长的时间要求所有 Linux 代码库的签入都由他审查。Anders Hejlsberg 仍然有效地批准每个 C# 语言设计更改。在我看来，架构师能够负担得起的每个重大决策越接近越好。

如果任其自生自灭，该团队将很快偏离正轨。这不是出于恶意，而是因为软件工程师的多样性。这种多样性存在于许多层面：技能水平、品味（这很难衡量：更多内容在下面的#2 中）、动机、职业道德、愿景的解释、个人信仰和经验，等等。架构师充当低通信号过滤器，消除任何偏离核心设计原则太远的不规则行为。

可悲的是，这种责任往往意味着成为“坏人”。有时你需要无情地扼杀一个想法，因为它会使项目的某些部分处于危险之中。其他时候你需要放弃一些不好的（但不是太有影响力的）想法。这里有一个权衡，因为每次你扼杀一个想法，你都会让某人感到被烧毁。你可能会浪费人们的时间，这取决于已经在这个想法上投入了多少时间。有些战斗最好不要打。这里有一门艺术需要学习：如果你能让那些有想法的人坚信必须有更好的方法，你就可以避免被视为坏人。“坐等”在某些情况下可以奏效，但也可能适得其反。

不幸的是，深入参与技术设计细节意味着如果架构师不小心，他或她可能会成为瓶颈。这会减慢团队的速度。诚然，一些放缓可能是一件好事，因为它会迫使在每一个决定中更加深思熟虑。但随着团队的成长，决策监督的粒度必然会发生变化，以确保团队有能力取得进展。为了使其发挥作用，您需要有可信赖的个人，他们参与的粒度更细，并且会使用相同的原则和价值观。这需要信任和时间。

---

事实上，良好的品味可能是建筑师需要具备的最重要的技能之一。糟糕的品味会导致没有人喜欢使用的笨重设计。史蒂夫乔布斯知道这一点。然而，品味可能是建筑师最难培养的技能，也是很少有人认为必要的微妙技能之一。许多管理人员认为，让更多的工程师解决设计问题就能解决问题，但实际上，通常只需要一个品位高超、注重细节的人。

我不确定品味从何而来：一种与生俱来的技能？也许，但不完全是。在我看来，良好的品位可以通过密切关注正确的事情、后退一步并经常从远处观察设计、了解过去构建和成功的软件类型以及拥有对代码的真正热爱。最后一部分听起来很俗气，但确实足以再次强调：如果你对你的代码和项目没有某种热情，那么让坏品味泛滥就容易得多，因为你的关心程度没有它那么强烈需要是。

---

编写代码还有利于确保您在团队中保持信誉。控制疯狂和宏大的想法很容易，但如果你是必须实施这种宏大想法的人，你可能会更加同情和关注团队中的其他工程师。您需要脚踏实地，编写真实的产品代码将有助于确保您的技术决策制定仔细考虑决策的可实施性和实际影响。

此外，您需要成为一名编程专家。人们需要尊重你的能力，你希望你的团队尊重你。你希望他们来征求你的建议，因为他们需要并享受它，而不是仅仅因为你在团队中的位置而强迫他们与你打交道。与我共事过的所有伟大建筑师都激励我成长，仅仅是因为他们见多识广，而且每次与他们互动时我都能学到新东西。如果他们不编写代码并且不了解技术深奥的本质，那么这种关系将是一种肤浅的关系。

---

架构师需要在理解业务和技术需求及策略方面发挥双重作用。架构师之间的商业悟性程度差异很大，尽管我认识的最好的架构师都具有独特的理解硬币两面的能力。但归根结底，他们首先是技术专家，而商业角度更像是一种好奇的爱好。在音乐中，两个音符一起发声形成二元音，而三个或更多音符形成一个和弦。我认识的最好的架构师意识到他们在业务端的相对弱点，并与另一位具有互补技能的高级领导者合作，以填补空白：这形成了和谐的间隔。一个二元组。

伙伴关系不必完全是“业务”与“技术”的关系，尽管在商业软件中这通常是两种对立的力量。例如，我对 Scheme 开发的印象是，Guy Steele 扮演架构师的角色，而 Gerald Sussman 是更面向业务的顾问，研究如何使用 Scheme 来推进更广泛的研究议程，但不一定干预项目的技术设计细节。

---

最优秀的工程师往往会成功，因为他们专注于解决个人的痛处。这就是 Linus Torvalds、Bjarne Stroustrup 和无数其他人所做的。这就是 Donald Knuth 创建 TeX 的原因。因此，一项新技术的想法开始时是一种非常个人化和自私的行为。“构建您自己使用的东西，客户就会来”是一个常见的（陈词滥调）成语。尽管这肯定是有道理的，但这只是因为它对创始工程师来说很麻烦这一事实很可能表明它对更广泛的人来说也很麻烦。这是一个示例，其中示例只是一组中的一个元素，用于演示该组中所有元素之间的某些公共属性。那些人是你的客户。

随着技术的成熟，重要的是要意识到——尤其是在构建商业软件时——真正的人会想要使用该技术。了解并尊重他们的需求很重要。在某些时候，重要的是要意识到您实际上并不是在构建一个完全供您个人使用的系统。没有意识到这一点可能会使您视而不见，并使您忽略与了解事物商业角度的人合作的必要性。它还可能导致需要开发完美的理想化解决方案并且永远不会交付给客户的感觉。嘿，当有无穷无尽的技术问题需要解决时，谁还愿意出货呢？根据其定义，交付软件意味着您已经解决了特定范围内的所有主要技术问题。那有什么好玩的？

---

一些建筑师可能会陷入使用教条而不是理智的陷阱。坚定的原则当然是我在整篇文章中强调的内容。但是你需要对自己诚实，并在事情进展不顺利时承认。一位建筑师站在一艘正在下沉的船上掌舵，宣称这艘船会继续航行，因为勇敢的新世界就在前方，但当船最终沉入水下时，他只会（独自）淹死。尽管这位架构师可以四处指责他的团队应该为失败负责（“如果他们只看到愿景并坚持下去，我们就会成功”），但到那时该项目将早已不复存在。主动识别问题并尽最大努力解决问题更难，但更崇高。

意识到很多人在你的手表上走错了方向可能会特别令人不安。是的，你浪费了他们的时间。但是你必须了解哪里出了问题，将其内化，并承诺永远不会犯同样的错误两次。你欠他们及时回应。团队中的每个人都会从这种情况中学习和成长，如果幸运的话，情况是可以挽救的。有时它不会。但无论如何，做出正确的决定都会赢得周围许多人的尊重；特别是如果您是唯一具有做出此类决定所需的广泛技术责任、理解力和洞察力的人，那么当您做出决定时，人们会感到宽慰。如果你做不到，人们会因此诅咒你。

那些不能读写代码的人必须把所有时间都花在说服其他人相信他们的想法上，而且通常与现实（即代码）完全脱节，以至于他们的想法在实践中行不通。这是一个糟糕的情况，尤其是在一家以代码为主要资产的公司。更糟糕的是，大多数人自愿将自己归入这一类别，尤其是随着时间的推移在他们的职业生涯中，因为他们认为编码“不是他们的工作职责之一”。什么垃圾！

---

第一个是我喜欢称之为“平庸的中层经理综合症”。我承认，当你管理足够大的团队时，你不得不放弃一些编码。我个人永远不会完全放弃它，即使我管理着 1,000 名工程师的团队。我将始终使用我的团队正在构建的产品，我将阅读签到以至少了解正在发生的事情并保持脚踏实地，并且假设我继续管理构建开发平台的团队，我将使用该平台编写代码。但对于负责 10 名或更少工程师的管理者来说，在这些方面绝对没有任何懈怠的借口。这样的团队往往在“成人监督”、工程文化以及为团队成员树立强大榜样方面受到影响。证据通常在布丁中，可以这么说。这样的管理者经常会增加负面价值。不幸的是，大公司的许多“软件开发负责人”都属于这一类，这不一定完全是他们的错，但主要是因为它在文化上被接受和鼓励。不用说，这在我的团队中是不可接受的。

第二个是我称之为“代码在我之下”的东西。两个最突出的例子是职业生涯后期的人和研究人员。前者经常与中层管理人员问题并存。但我也看到它也困扰着软件工程师：“我已经做了 10 年的专业开发人员，所以我现在的工作是告诉别人该做什么，而不是自己做任何事情。” 在这一点上，他们可能会采用架构师的头衔。然而，坦率地说，这个研究问题让我很困惑。计算机科学是纯数学和应用工程的奇怪混合体。我知道许多 CS 研究人员更偏向于数学，并且希望基本上做数学而不是软件。我也明白这项研究的大部分成果。但根据我的经验，有很大一部分研究人员没有产生“一流的数学，” 并且拒绝以代码为基础。你可以改善软件的状态，其血统是代码，而无需编写一行代码或精通它，这种想法完全是疯狂的。然而它被普遍接受。

最后一个例子是“我管理事物，而不是构建它们”，这是我自己在职业生涯早期犯下的这个错误后最接近的例子。即使是在 CS 方面有深厚背景并且一生都在编写代码的人，最终也会来到这里。但通常情况下，留在这里的人不喜欢代码，但最终可以“负责”做出​​有关功能、优先级、竞争性产品等的决策。确实，有些人有很好的直觉，可以做出一些在不知道事情是如何运作的情况下做出好的决定（尽管这种情况很少见）。但是当涉及到软件时，一切确实都需要以代码为基础，否则决策往往是不连贯的和有害的。无论如何，如果代码不有趣，还有很多其他学科，比如销售和营销、人力资源、或大型公司中的许多其他组织之一，其重点不在于实际构建软件。热爱代码的人应该是开发者，并以此为荣。

对于掉入这些陷阱中的任何一个，但随后意识到并摆脱困境的人，我怀有极大的敬意。嘿，我自己就是这样做的。

权威之所以是权威，在于他做正确的事情比做错误的事情要多，但并不意味着他所有的决定都是正确的。

反抗权威也是有风险的，最好的策略或许是，在一个无关面子和具体利益的场景下讨论各种可能情况，但是在公开场合，做一个老好人？

---

当我第一次来到微软时，我突然被许多聪明人包围，无论他们正在建设什么，他们都充满动力和活力。这让我最初假设这些人知道发生了什么。这让我假设，仅仅因为某个人拥有“公司副总裁”或“杰出工程师”的头衔，他们就知道发生了什么。事实上，在我上班的第一天——我永远不会忘记这一点——我在一次设计会议上“大胆”地告诉另一个 DE（微软当时最高级别的技术职位）我不同意他在说。我对此很有礼貌，直到今天我认为我是对的。然而，后来我被拉到一边，说这是多么愚蠢的举动。更糟糕的是，实际上，我头两年都在听，并且竭尽全力不让船摇晃太多。这违背了我更好的判断。我还年轻，来自另一份工作，在那里我有信心并且可以放心地质疑任何事情；但我犯了一个愚蠢的错误，认为“好吧，也许这里的情况有所不同。” 我仍然希望我能回到那两年。

请允许我告诉你一个小秘密。（嗯，好吧，这并不是真正的秘密，但要是我能回去告诉年轻的自己就好了。而且我想这应该是显而易见的。）这些人并不总是知道发生了什么。可以安全地假设这些人在他们的职业生涯中得到了回报，因为从统计学上讲，他们正确的次数多于错误的次数。但这仍然只是统计数据。老实说，如果他们有任何优点，他们会喜欢被质疑。他们喜欢技术辩论。这是一个伟大团队的一个重要方面。

---

我最喜欢的员工是那些会提出大量问题并且在我错了时不怕告诉我的员工。这些人对一切都充满好奇，无论是高度技术性的还是纯商业性的。通过质疑我自己的观点并迫使我阐明它们，文化得到了全面加强。作为领导者，我不仅需要有条不紊地思考和捍卫我解决问题的方法，而且我周围的人也会受益，因为 (a) 他们通常最终会对组织产生重大影响，并且 (b) 即使我的最初的立场得以保留，他们理解某些决定背后的基本原理，并因此得以成长。这很有趣！– 尽管有时会热情洋溢。

---

现在，你不能成为一个混蛋。而且你不能自大。软件是关于人和协作的，所有这些问题都必须牢记一个目标：让软件、组织和/或其人员变得更好。权威的存在是有原因的，那就是最终需要有人来经营企业、做决定，并让他们的屁股在线。有时简单的现实是领导者的直觉非常好，尽管可能缺乏数据来支持决策，但您可以相信它。可以同意不同意，或者有时承认某人在特定领域的背景比你强，所以你可能无法完全理解为什么做出某个决定。我一直试图把这样的场合变成学习的机会。记下一些笔记，然后去阅读它。我总是记下并研究我听到的任何我不完全了解的术语，无论是技术术语还是业务术语。它一直在发生。

---

UPDATE: 看上去这是一个很不错的建议。试着挑出组织里面的一些毛病或者是问题，并且礼貌地表达出来：如果他们觉得收到伤害而不录用你，那么说明这个公司也不怎么样。

在你的下一次工作面试中，特意去质疑一两件事。如果对方的行为被冒犯了，要么你问错了方式（记住：尊重但好奇），要么你不应该接受这份工作。如果它是一家初创公司，请提前阅读商业计划，并准备好一些棘手的问题。如果是一家公司，问问奖励是什么，找出技术架构中的漏洞，质疑工程流程中可以改进的地方。我真的认为这是一个运作良好的团队最重要的文化特征之一。我保证你会在这样的团队中获得更多乐趣，这也许是最重要的文化特征。

现实情况是，世界上真正令人惊叹的软件开发人员的数量是有限的（读作：少数），尤其是与提供给他们的机会和激动人心的项目相比。

然而，伟大的团队首先是由伟大的人推动的。我经常将此比作格言“水涨船高”。

---

将这种想法应用到团队中，意味着你应该始终努力雇佣越来越优秀的人。这样一来，团队的整体素质就会提高。雇用越来越优秀的人会对文化产生非线性影响，因为团队不仅仅是一组不相交的节点，而是一个完全连接的个人图，他们一起进行对话和协作。更高的团队整体素质意味着更丰富的联系以及更强大、更高质量的创新和软件。这意味着你真正改变世界的机会也在非线性地增长。

我努力只雇用在某些有趣的方面比我和团队中已有的人更好的人。一旦你让你的高标准下降哪怕一盎司，平均水平就会下降，并且会产生累积的滚雪球效应。连接变弱，质量和创新将出现非线性下降。这是我的噩梦场景，因为它会很快走下坡路。

---

作为领导者，您应将所有这一切归功于您现有的团队。通过提升船只，您的整个团队都会受益。他们成长，学习新事物，并在自己的职业生涯中达到新的高度。

尽管工作很辛苦，但这一切最终都得到了回报。我觉得生活中没有什么比建立和发展一支优秀的团队、看到逐年的进步以及共同创造令人惊叹的事物更令人满足的了。甚至可能不仅仅是编码。

今天走捷径虽然很有吸引力，因为它们有助于在下一个最接近的最后期限前完成任务，但你几乎总是要为此付出代价。您随后可能会陷入错误的泥潭，因为质量从一开始就受到了损害。您可能创建了一个其他人构建的平台，后来才意识到该架构是错误的，需要进行改造，从而对整个软件堆栈产生连锁反应。你可能会意识到你的整个系统在负载下表现不佳，以至于当你的创业公司开始飞速发展到成功时，用户反而因为糟糕的体验而逃离。表现形式不同，但根源是一样的。

项目所需的质量水平因您的技术和业务而异。例如，我承认在系统软件上工作需要与网络软件不同的质量标准。随着项目的成熟，当重点从编写大量新代码转移到修改现有代码时，质量要求也会发生变化……尽管早期阶段实际上是最具挑战性的：这是最关键的文化特征尚未确定但已经确定的时候发展中，当事情最有可能朝着错误的方向发展时，并且由于需要同时在广泛的问题上取得快速进展，您最有可能在质量上吝啬。

---

作为领导者，重要的是要营造一种文化，让个人因做正确的事而获得奖励。没有什么比拥有一个由使用一套共同的严格原则“自我监督”的人组成的团队更好的了。

为实现这一目标，领导者需要始终如一、要求严格，并且高度了解周围发生的事情。您需要能够识别质量与垃圾，以便您可以奖励合适的人。你需要建立一种文化，在这种文化中，当采取捷径时，批评反馈是“好的”和“预期的”。我在之前的文章中已经非常明确地表达了我的信念，但我只是不相信您自己在技术不高的情况下无法在早期就做到这一点。随着团队的壮大，您对技术细节的关注可能会越来越少，在这种情况下，您需要通过增加分享、认可、维护或推进这些文化特征的新技术领导者来扩大规模。

---

UPDATE: 这点我倒是真没有想过。的确有时候遇到一些问题，当时可以绕过去，但是事后最好过来在想想看。或许你会学习到新的东西，或许你之后可以真正避免这些问题而不用恐惧他们。

我有一个我几乎不好意思承认的信念：我相信大多数人都非常懒惰。我认为大多数质量妥协源于一种内在的懒惰，这种懒惰导致细节被掩盖，即使它们有意识地被认为需要注意。最好的开发人员保持这种来自内心深处的近乎超自然的驱动力，并且他们使用这种驱动力来避免懒惰。如果您正在快速行动并编写大量代码，请努力利用您可以聚集的每一盎司智力马力——持续，在您编写代码的整个过程中。即使那是连续 16 个小时。如果在任何时候出现一个可以节省你在路上的时间的想法，停下来，思考它，在飞行中纠正方向。这是一种“减速以加速”的方式，但您仍然可以快速移动。许多懒惰的人没有充分探索这些转瞬即逝的想法。他们会有意识地做错事，因为做正确的事需要更多的时间。

些年来我养成了奇怪的习惯。在编译运行时，我仔细研究了每一行修改过的代码，想知道是否有更好的方法来做到这一点。如果我看到什么，我将它压入堆栈并确保返回到它。到我实际提交一些新代码时——无论是 10,000 行新编写的代码，还是对某些现有内容的 10 行修改——我很可能已经至少阅读每行代码三遍。我不允许我看到的任何细节从裂缝中溜走。而且我的思想困扰着我工作的方方面面，即使是在“休息时间”（例如，吃晚饭、走在走廊上等）。这些机会中的每一个都代表了放慢速度、反思和纠正路线的机会。

Code Review 可以反应出团队的很多方面，也可以快速地了解项目进展和细节。另外程序员虽然不太喜欢微管理，但是看到自己的代码被别人review也会感觉很好。

代码签入是一个非常好的了解团队的入口，你可以基于此提出许多问题。我相信并不是每个团队都可以解决好这些问题的，关键是他们取舍在哪里，整个系统成熟度如何等等问题，都可以从这里引出。

---

加入新团队时，我问的第一个问题是：代码审查在哪里进行？

答案和参与此类评论的经验会立即告诉您很多关于团队的信息：

• 有工程严谨性吗？
• 团队的开放程度如何，例如，它更像是一个“封闭团队”还是“欢迎所有人”之类的地方？
• 团队文化是否包含技术辩论和讨论？
• 谁是团队中的牛逼程序员？
• 团队的职业道德是什么，例如，人们是全天候签到，包括周末，还是只是朝九晚五？
• 相关的，团队是否富有成效？
• 我们实际上在构建什么，开发人员如何度过他们的时间？我们是否朝着一致的方向前进？
• 人们是否有自己的舒适区，或者开发人员是否在整个代码库中进行协作？具体有哪些区域？
• 与修复现有代码（错误）相比，在编写新代码上花费了多少精力？
• 环境更像是一个原型并边走边学，还是签到总是带有固定的设计规范？
• 开发人员在编写代码时是否关注性能等问题，例如，他们是否经常引用测量结果？
• 我们的工程工具如何，尤其是在代码审查和代码共享方面，它们是否运行良好？
• 个人如何很好地传达他们的想法，例如签到记录是简洁和难以理解的，还是表达清晰和深思熟虑的？

---

作为技术领导者和经理，代码审查和签入实际上是您团队的心跳。虔诚地阅读它们——虽然公认很耗时——是真正理解团队在做什么及其优缺点的绝对必要条件。如果你要加入一个新团队，它会让你处于工程对话的核心，并且能够开始修复任何损坏的东西（打开它、鼓励辩论、改变技术方向等）。到了校准会议的时候，您已经深入了解谁在实际完成工作，以及谁在编写质量代码。您会非常明显地看到技术领导者，包括真正为团队其他成员设定步伐的人（编码输出、良好的反馈、职业道德等）。

有时，您甚至可能会找机会自己提出一个小建议。有些人可能认为这是微观管理，但我发现开发人员真诚地感谢他们的老板或老板的老板或任何真正关心的人花时间在这种细节级别上了解他们的工作。

也有相反的情况，这有助于让团队保持警惕。

不要自我设置边界，打破边界去做事情，一方面你可以学到更多的知识，另一方面在产品上可以做到更好的end-to-end的用户体验，优化整个产品。

抽象是件好东西，但是它的cost/value必须放在特定的context下面重新评估。

---

显然我现在的情况有点特殊。并不是每个人都同时在开发平台和操作系统以及两者之间的所有方面工作。但是这方面的机会比人们想象的要多；事实上，它无处不在。它可以是网站或应用程序的用户界面与业务逻辑、硬件与软件、工程系统与产品代码、运营与测试与开发等。大多数人都有他们不会跨越的神圣界限。当这些界限受到组织边界的驱动时，当工程师们应该打破界限并跨越界限进行协作时，这让我感到难过。

---

从缝合在一起的一系列黑匣子的角度思考会在地板上留下机会，无论是规模经济还是创新机会，特别是如果没有人负责跨越这些边界进行端到端的检查以确保它们有意义。抽象提供了一定程度的独立性，但我总是经常退后一步想知道，“这种抽象让我付出了什么代价？它对我有什么好处？权衡是对的吗？抽象很棒，只要它们在正确的位置，而不是出于组织动机。最大的罪过是故意创建质量较差的解决方案，仅仅是因为害怕跨越或与这种抽象边界另一端的工程师打交道。

协同开发与构建正确的架构一样重要，因为它正在验证该架构及其实施。如果你被迫考虑——甚至遭受后果——你刚刚编写的语言特性的最终代码质量，并且你被迫看到它的实际效果，并通过实际将该特性集成到某些语言中来获得目标受众的反馈“真实世界”的代码，你不太可能把问题藏起来。特别是如果您采取了正确的措施。过去，我曾无数次将一些很酷的功能组合在一起，然后转向下一个功能，却发现（通常是在向客户发货之前）它在现实世界中不起作用。我一直专注于开发者平台示例，但显然这些想法远远超出了开发者平台。

无论您是多么聪明的领导者，有时您都会犯错。经常甚至。你不会总是有最好的想法。

这有三个原因。

首先，数字对你不利。（我理解就是人数）

其次，你团队中的人拥有的数据比你可能拥有的多得多。这并不是说每个人都有更多的数据——我一直惊讶于与我共事过的一些最优秀的领导者可以搜索和保留多少数据——但从统计学上讲，你会有盲点，而且某些人每次都会在深度上大大超过你。记忆和时间是有限的，所有。

第三，无论如何，在你的团队中，总有一些人比你有更好的想法，比你更聪明。

---

至关重要的是要创造一个环境，让最好的想法能够被听到、讨论，并最终能够成长为更大的东西。您公司的下一个巨大成功可能就在您的眼皮底下，在这些想法没有发言权的环境中，您会遭受双重损失：首先，您没有利用这个想法；其次，此人可能会将他们的想法带到别处。聪明和有创造力的人需要出路。

我还认为必须对想法保持开放的心态。如果您不是提出这个想法的人，那么一种可能性是这只是个坏主意。不幸的是，太多人都这样认为。更有可能的是，它背后的某些方面是您并不真正欣赏的。从不同的角度思考问题很重要。我一次又一次看到的一个陷阱是基于你的偏见急切地摒弃一个想法，比如过去的经验（今天可能没有以前那么重要），对一个团队的战略方向的坚定控制（比如痴迷于“赚钱”，而您真正需要的是进行一些关键的“架构”投资，以奠定以后获得回报的基础），等等。

---

UPDATE: 这里要区分“独裁”和独裁。

在某些群体中，独裁者模式可以“奏效”。我把工作放在引号中是因为这些往往是保守和受限的环境，在这些环境中保持低创新是可取的。不过，我不能说这是我想工作的任何地方。

不要将此与其他本质上显得独裁的模式混淆，例如苹果公司的史蒂夫·乔布斯和微软早期的比尔·盖茨。这种模式可以很好地发挥作用，即有一个人在监视，以确保公司所做的一切都尽可能最好、一致，并根据组织的战略交付。史蒂夫乔布斯对想法非常开放，事实上，这在很大程度上推动了苹果公司，尽管他很快就撕毁了坏想法（而且，我敢肯定，一路上有一些好想法）。自下而上的创新并不意味着任何人都可以为所欲为，但这确实意味着每个想法都会在法庭上得到公平的对待。谷歌和 Facebook 明白这一点。

我在优秀的团队成员身上寻找一个特别重要的特质：知识上的诚实。许多其他特征通常会效仿，但缺乏这个基础会导致频繁出现小林丸情况。最好的情况是，这些会拖慢团队的速度而不会增加价值，而最坏的情况是，会使整个团队变得有毒并破坏其核心文化价值观。而且它可以很快发生。

与我共事过的最优秀的工程师和领导者对事物的运作方式有着永不满足的好奇心，渴望发现如何把事情做得更好，并且从根本上理解职业是一生的学习。如果你不知道什么，这是一个学习的机会，而不是掩盖你不知道的事实。每个人都缺少信息。不可能将知识世界掌握在一个人的头脑中（至少以当今的技术而言）。最好的领导者知道这一点，并会提出无穷无尽的有见地的问题。

另一方面，最糟糕的工程师和领导者会伪造它，或者更糟的是，它们会主动回避真相。他们感到不安全，开始了一场系统性的知识分子不诚实运动。我敢肯定，在您的职业生涯中，您至少与一位这样的人共事过。我从来不确定这样的人是否有意识地这样做。可能是一些内在的本能开始起作用。但不管是什么，你必须训练自己——和你的团队——永远不要走这条路，并无情地抓住并压制这种不良行为。