为什么分布式领导比指挥控制更高效

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您翻译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！

Introduction

我承认，我花了十年的时间做一名专业的提醒者。我以为那就是工作。我以为成为 “Senior Leader” 就是那种盯着时钟、检查清单的人。我相信如果我不把眼光放在每一行代码和看板上的每一张工单上，整艘船都会沉。

我把它称为 “High Performance.” 我把它称为 “Maintaining Standards.” 但如果我对你坦诚，这其实只是一种非常礼貌的恐惧。

我害怕变得无关紧要。我害怕如果团队能够在没有我的情况下前进，公司会意识到他们不需要我。于是我构建了一个系统，让自己成为瓶颈。我成了轮子的中心。每一个决定都必须经过我的桌面。每一个 deliverable 都必须盖上我的章。

我以为自己在当英雄。现在我意识到，我只是一堵墙。

如果你今天正在领导一个技术团队，你可能会感受到 “Metallic Cold.” 你感受到加速的压力。你感受到对更快速度和更高产出的持续需求。行业告诉我们，达成目标的方式是通过更好的度量和更紧的控制。

但我在这里告诉你， “Foreman” 心态是构建软件的最低效方式。指挥‑控制式的领导是工厂时代的遗物，在充满创意工程师的房间里毫无立足之地。

我必须通过艰难的教训才明白的真相是：分布式领导不仅仅是对人“好”的方式。它是在人性化的同时，构建真正持久事物的唯一途径。

救世主的神话

我们在技术领域有一个 “英雄”问题。我们奖励熬到凌晨 3 点去修复生产缺陷的人。我们赞颂每次跳进 PR “拯救”代码的负责人。

我曾经就是那个人。我喜欢拥有所有答案的快感。我以为我的牺牲是对团队的礼物。我以为自己在为他们抵御压力。

但当我成为英雄时，我实际上在偷走他们的成长。

当你从控制的立场去领导时，你会培养出一支 “用户” 队伍。他们等待你的指示。他们等待你的批准。他们不再为自己思考，因为他们知道你最终会替他们思考。

这极其低效。它形成了一个系统，整个团队的速度受限于某个人的大脑速度。那个人通常又累、又有压力，且与实际工作脱节。

我每天早晨都感受到这种沉重。我会看着日程表，看到一格格别人的优先事项。我对自己的头衔负了债。我已经变成了我曾经讨厌的那种人——一个不再真正懂得如何构建任何东西的管理者。

为了解决这个问题，我必须做一件可怕的事：我必须 放手。

信任是终极低延迟网络

在工程实践中，我们花费大量时间来减少摩擦。我们优化流水线，重构代码，寻找从想法到部署的最短路径。

团队中最大的摩擦来源是缺乏信任。

当你采用指挥‑控制结构时，每一次决策都会引入巨大的延迟。工程师有了一个想法，却必须等会议；他们必须向几个月未触碰代码库的经理解释这个想法，而该经理又要去找另一位经理确认。

等到想法获批时，灵感已经消散。工程师只是在执行任务，而不是在解决问题。

分布式领导——或者我喜欢称之为 “种花园”——就是要消除这种延迟。它把决策权下放到真正动手“触土”的人手中。

当一个团队拥有自己的工作时，它的运转速度是任何经理都无法强制的。它不是为了满足墙上的某个指标而工作，而是因为它在乎自己所构建事物的涟漪效应。

信任不是软技能，而是技术优势。它是让团队自行弥补缺口的燃料。如果你必须强制一个系统，说明系统已经出现问题。一个优秀的团队应该像森林一样：自行生长、适应并维持自身，而不需要站在一旁拿着剪贴板的工头。

工作的灵魂

企业界常说管理是关于 “让事情发生”。

但如果我们诚实一点，这往往只是意味着确保人们坐在自己的位置上。我们把办公室——甚至是数字化的办公室——当作工厂车间。我们用功能列表的长度来衡量自己的价值。我们认为只要动作够快，就能跑赢那种我们只是算法的中间人的感觉。

我正坐在桌前，看着阳光，记得自己不仅仅是一连串成功的部署。我的团队也不只是一个速度图表。

当你转向分布式模式时，你终于承认了你所领导的人的人性。你在说：

“我信任你的推理。我信任你的良知。我信任你会关心水，而不仅仅是船。”

这会改变房间里的空气。它不再是 监控，而是 管家式的管理。

我们要对我们产生的涟漪负责。那涟漪不仅止于代码；它触及到我们工程师的家庭，以及他们在一天结束时合上笔记本电脑时的感受。

如果你的领导风格让人感觉自己像机器，即使你达成了所有日期，即使你的“优化”完美无缺，你也在让他们失望。你在失败，因为你正在制造一种 “金属寒冷”，最终会把每个人都烧尽。

如何开始重构

如果你已经厌倦了充当英雄，今天就可以开始重构。它不需要新的框架，也不需要更改你的 Jira 设置。

这需要你有足够的勇气说出 “我不知道。”

下次团队成员向你提出问题时，不要直接给出解决方案——即使你已经有了解决方案，甚至确切知道该修改哪个文件。相反，向他们提问：

“你认为我们应该怎么做？”

然后，做最难的那一步。保持沉默，让沉默在房间里蔓延。给他们空间，让他们走入自己的领导角色。你可能需要看着他们挣扎片刻，甚至看到他们犯错。但正是这种挣扎孕育了成长。这正是 “资源” 变成 “合作伙伴” 的时刻。

我帮助技术领袖摆脱头衔的束缚，开始关注“水”。我相信我们的工作不是把人变成机器，而是把团队培育成花园。

我们是超越软件的遗产的建筑师。我们正在构建未来孩子们将要工作的文化。让它成为充满活力的文化，让阳光能够照进地板。

停止只关注船只本身，水更重要。

修补程序：“I Don’t Know”脚本

如果你想开始分担领导的重担，请在下次会议中尝试这样做。

当有人向你询问通常由你单独做出的决定时，回答：

“我有一些想法，但我担心我的视角离代码太远。我想信任你的直觉。你的直觉告诉你正确的前进方向是什么？”

然后，倾听。不要纠正。不要*“优化”。*只要倾听。你正在播下种子。它需要时间才能成长，但果实值得等待。

我撰写关于技术领导、共享所有权以及在机器驱动的行业中保持人性化的内容。如果这段文字引起了你的共鸣，你可以在 newsletter.diamantinoalmeida.com 找到我的更多作品。