技术领导力：如何通过授权帮助工程团队成长

在工程管理中，团队成长需要给成员留出犯错和承担责任的空间。对技术负责人来说，最大的挑战之一，就是判断哪些错误只是“小擦伤”，哪些错误会带来严重后果。真正有效的技术领导力，不是事无巨细地控制团队，而是在高标准下给予团队足够的自主权。

我们都见过那种“直升机父母”：他们时刻盘旋在孩子身边，生怕孩子一不小心摔倒。我们发誓自己绝不会那样做。我们会给孩子足够的成长空间，让他们从错误中学习。

然而，当我们成为技术负责人后，却常常变成了最糟糕的那种“直升机领导”。

我自己就犯过微观管理的错误。

一开始是在代码审查中。我会对看到的每一个小问题都提出意见。我的理由是：我只是想设定高标准而已。

后来，这种习惯逐渐发展到团队的每一个设计决策。我会忍不住插手、评论、纠正。我的理由是：我只是想确保我们走在正确的方向上。

其实，当我开始成为团队瓶颈时，就应该意识到问题了。但说实话，直到一些团队成员开始对我不满，我才真正意识到发生了什么。我们现在是很好的朋友，但那段时间确实有点紧张。

避免微观管理：先让开一点

一支优秀的工程团队，终将成长到超出你个人能力边界的程度。

如果你事无巨细都要插手，团队的才能最终会被埋没。你需要的是一支真正的工程师团队，而不是一群只会按指令写代码的“程序员”。所以，请像对待工程师一样对待他们，给他们足够的空间去发挥所长。

团队学习和成长的最佳方式，是让他们承担责任，允许他们犯错，并从错误中吸取教训。这些亲身经历，往往比他们从某些博客文章里读到的东西更有价值。

当然，这不仅仅是赋能他人的问题。你自己也有很多重要的事情要做。

如果你把所有时间都花在日常决策上，就意味着你没有时间思考长期战略。而如果你在长期战略上出错，未必有人能替你收拾残局。所以，不要把所有时间都耗在本该由别人承担的问题上。

团队授权不是放低标准

先别误会。

这一部分并不是要你放松要求，任由团队把事情搞砸。

千万别那样做。

允许团队经历一些“小擦伤”，目的应该是为公司带来整体收益。我们不是在做慈善。

成员需要自主权，才能充分发挥潜力。他们需要犯错的空间，才能真正从中学习；他们也需要你提供组织层面的支持，才有机会做到这一点。

但是，如果缺乏对质量和执行结果的问责，任何人都学不到东西。那就不是成长，而是在敷衍。

自主性必须和清晰预期结合在一起。你仍然需要设定期望，询问项目何时完成，并和团队一起复盘工作是否成功。

对于研发团队来说，授权并不意味着过程不可见，而是要让目标、任务、质量标准和复盘结果有据可循。像 PingCode 这样的智能化研发管理工具，可以帮助团队把目标制定、客户反馈、需求评审、开发测试、发布上线和 Wiki 经验沉淀串联起来，让技术负责人既能减少不必要的微观管理，又能通过数据和流程把握关键风险。

用含糊其辞的话来糊弄团队没有意义，所以也没必要假装同意他们的所有观点。下面这些话，往往能很好地激励工程师：

我不确定自己是否完全同意你的判断，但这个决定由你来做。你可以做到。继续推进吧，不过我的期望是……

或者：

如果你需要建议，随时告诉我。否则，我就不插手了。你知道我们需要什么，也知道什么时候需要。这个事情由你负责，全力推进吧。

试试这些表达。你可能会发现，团队成员的效率和投入度明显提升。

工程生产力与积极性密切相关。自主性加上高标准，对优秀工程师来说是一种巨大的激励。

工程管理中的第一类决策与第二类决策

说到这里，一切听起来似乎只是管理学大道理。那么，真正的难点在哪里？

为了避免刚才说得过于理想化，我们必须承认：如果你给予团队自主权，而最终导致灾难发生，那就是你的责任。

你要对团队方向和执行结果负责，不能撒手不管。

赋予他人自主权本身就有风险。最稳妥的做法，当然是对团队进行事无巨细的微观管理。这样做的结果是：你大概率会得到一群平庸的人，产出平庸的成果，而真正优秀的人才会选择离开。

但这应该不是你想要的结果。

真正有洞察力的技术领导力，在于能够分辨：哪些决策一旦出错会造成严重伤害，哪些决策最多只是带来轻微损失。

有人将这类决策分为第一类决策和第二类决策。

第一类决策重大、难以逆转，一旦出错后果严重。第二类决策则没有那么关键，可以撤回，也可以稍后调整方向。

你当然需要掌控第一类决策，但不必过度担忧第二类决策。

至于什么属于第一类，什么属于第二类，并没有简单答案。很遗憾，你需要自己判断。

在软件工程语境下，我通常会把以下事项视为第一类决策：

• 外部 API，至少包括主要设计细节；
• 分布式系统协议；
• 正确性、可验证性和可靠性标准；
• 安全相关决策；
• 是否要在某个项目上投入大量资源，例如大型系统重写；
• 长期团队战略。

至于其他事情？只要你对聪明人提出高标准，很多问题其实没那么严重。

想在项目内部使用库 X 而不是库 Y？可以。我通常不会太在意。

如果你是设计评审中的高级工程师，可以先想一想：这个决策到底是不是第一类决策？如果只是第二类决策，也许你应该更委婉地提醒大家，而不是过于强硬地介入。

如果你是正在寻求反馈的初级工程师，也可以先弄清楚：你面对的是第一类决策，还是第二类决策。因为如果你直接要求设计反馈，无论你是否喜欢，你很可能都会得到反馈。

技术负责人也可能是错的

到目前为止，这篇文章似乎把技术负责人描绘成了无所不知的天才。这有点过头了。

你很可能并不是天才。

让团队成员经历一些“小擦伤”的好处之一在于：很多时候，他们最终根本不会受伤。事实证明，错的人是你。

你的工程师很可能比你更了解他们负责的那部分技术栈。他们也很可能比你更认真、更深入地思考过某个具体决策。

当然，他们的经验可能不如你丰富。但他们完全有可能证明你是错的。

很多时候，最后的结果是：那个决策其实没有那么重要，你们两个人都没错。又或者，你们确实浪费了一些时间，但工程师因为承担了责任，投入度更高，最终整体结果仍然是平衡的。

所以，请关注团队的中期成果，而不是短期得失。

承认自己判断错误，是让团队取得比个人单打独斗更大成就的重要路径。

授权也要循序渐进

这一点或许显而易见，但仍然很重要：你应该赋权给那些已经准备好承担责任的人。

即使是第二类决策，初级成员也仍然需要一定指导。这并不意味着你可以免除自己提供建议和辅导的责任。

如果团队成员已经感到压力过大，就说明你做得太过了。

不要把实习生直接推入深水区，然后期待他们自己游上岸。

总结：用高标准授权，让工程团队成长

赋予团队决策自主权，允许他们经历一些“小擦伤”，但同时要提出高标准。

运用你的判断力，区分哪些决策至关重要，哪些决策可以逆转。

当团队成员拥有自主权和责任感时，团队会成长得更快，效率也会更高。

如果最后证明我们确实犯了一点小错，浪费了一些时间？那就下次加倍努力，把这次经验赚回来。