在工程管理中团队成长需要给成员留出犯错和承担责任的空间。对技术负责人来说最大的挑战之一就是判断哪些错误只是“小擦伤”哪些错误会带来严重后果。真正有效的技术领导力不是事无巨细地控制团队而是在高标准下给予团队足够的自主权。我们都见过那种“直升机父母”他们时刻盘旋在孩子身边生怕孩子一不小心摔倒。我们发誓自己绝不会那样做。我们会给孩子足够的成长空间让他们从错误中学习。然而当我们成为技术负责人后却常常变成了最糟糕的那种“直升机领导”。我自己就犯过微观管理的错误。一开始是在代码审查中。我会对看到的每一个小问题都提出意见。我的理由是我只是想设定高标准而已。后来这种习惯逐渐发展到团队的每一个设计决策。我会忍不住插手、评论、纠正。我的理由是我只是想确保我们走在正确的方向上。其实当我开始成为团队瓶颈时就应该意识到问题了。但说实话直到一些团队成员开始对我不满我才真正意识到发生了什么。我们现在是很好的朋友但那段时间确实有点紧张。避免微观管理先让开一点一支优秀的工程团队终将成长到超出你个人能力边界的程度。如果你事无巨细都要插手团队的才能最终会被埋没。你需要的是一支真正的工程师团队而不是一群只会按指令写代码的“程序员”。所以请像对待工程师一样对待他们给他们足够的空间去发挥所长。团队学习和成长的最佳方式是让他们承担责任允许他们犯错并从错误中吸取教训。这些亲身经历往往比他们从某些博客文章里读到的东西更有价值。当然这不仅仅是赋能他人的问题。你自己也有很多重要的事情要做。如果你把所有时间都花在日常决策上就意味着你没有时间思考长期战略。而如果你在长期战略上出错未必有人能替你收拾残局。所以不要把所有时间都耗在本该由别人承担的问题上。团队授权不是放低标准先别误会。这一部分并不是要你放松要求任由团队把事情搞砸。千万别那样做。允许团队经历一些“小擦伤”目的应该是为公司带来整体收益。我们不是在做慈善。成员需要自主权才能充分发挥潜力。他们需要犯错的空间才能真正从中学习他们也需要你提供组织层面的支持才有机会做到这一点。但是如果缺乏对质量和执行结果的问责任何人都学不到东西。那就不是成长而是在敷衍。自主性必须和清晰预期结合在一起。你仍然需要设定期望询问项目何时完成并和团队一起复盘工作是否成功。对于研发团队来说授权并不意味着过程不可见而是要让目标、任务、质量标准和复盘结果有据可循。像PingCode 这样的智能化研发管理工具可以帮助团队把目标制定、客户反馈、需求评审、开发测试、发布上线和 Wiki 经验沉淀串联起来让技术负责人既能减少不必要的微观管理又能通过数据和流程把握关键风险。用含糊其辞的话来糊弄团队没有意义所以也没必要假装同意他们的所有观点。下面这些话往往能很好地激励工程师我不确定自己是否完全同意你的判断但这个决定由你来做。你可以做到。继续推进吧不过我的期望是……或者如果你需要建议随时告诉我。否则我就不插手了。你知道我们需要什么也知道什么时候需要。这个事情由你负责全力推进吧。试试这些表达。你可能会发现团队成员的效率和投入度明显提升。工程生产力与积极性密切相关。自主性加上高标准对优秀工程师来说是一种巨大的激励。工程管理中的第一类决策与第二类决策说到这里一切听起来似乎只是管理学大道理。那么真正的难点在哪里为了避免刚才说得过于理想化我们必须承认如果你给予团队自主权而最终导致灾难发生那就是你的责任。你要对团队方向和执行结果负责不能撒手不管。赋予他人自主权本身就有风险。最稳妥的做法当然是对团队进行事无巨细的微观管理。这样做的结果是你大概率会得到一群平庸的人产出平庸的成果而真正优秀的人才会选择离开。但这应该不是你想要的结果。真正有洞察力的技术领导力在于能够分辨哪些决策一旦出错会造成严重伤害哪些决策最多只是带来轻微损失。有人将这类决策分为第一类决策和第二类决策。第一类决策重大、难以逆转一旦出错后果严重。第二类决策则没有那么关键可以撤回也可以稍后调整方向。你当然需要掌控第一类决策但不必过度担忧第二类决策。至于什么属于第一类什么属于第二类并没有简单答案。很遗憾你需要自己判断。在软件工程语境下我通常会把以下事项视为第一类决策外部 API至少包括主要设计细节分布式系统协议正确性、可验证性和可靠性标准安全相关决策是否要在某个项目上投入大量资源例如大型系统重写长期团队战略。至于其他事情只要你对聪明人提出高标准很多问题其实没那么严重。想在项目内部使用库 X 而不是库 Y可以。我通常不会太在意。如果你是设计评审中的高级工程师可以先想一想这个决策到底是不是第一类决策如果只是第二类决策也许你应该更委婉地提醒大家而不是过于强硬地介入。如果你是正在寻求反馈的初级工程师也可以先弄清楚你面对的是第一类决策还是第二类决策。因为如果你直接要求设计反馈无论你是否喜欢你很可能都会得到反馈。技术负责人也可能是错的到目前为止这篇文章似乎把技术负责人描绘成了无所不知的天才。这有点过头了。你很可能并不是天才。让团队成员经历一些“小擦伤”的好处之一在于很多时候他们最终根本不会受伤。事实证明错的人是你。你的工程师很可能比你更了解他们负责的那部分技术栈。他们也很可能比你更认真、更深入地思考过某个具体决策。当然他们的经验可能不如你丰富。但他们完全有可能证明你是错的。很多时候最后的结果是那个决策其实没有那么重要你们两个人都没错。又或者你们确实浪费了一些时间但工程师因为承担了责任投入度更高最终整体结果仍然是平衡的。所以请关注团队的中期成果而不是短期得失。承认自己判断错误是让团队取得比个人单打独斗更大成就的重要路径。授权也要循序渐进这一点或许显而易见但仍然很重要你应该赋权给那些已经准备好承担责任的人。即使是第二类决策初级成员也仍然需要一定指导。这并不意味着你可以免除自己提供建议和辅导的责任。如果团队成员已经感到压力过大就说明你做得太过了。不要把实习生直接推入深水区然后期待他们自己游上岸。总结用高标准授权让工程团队成长赋予团队决策自主权允许他们经历一些“小擦伤”但同时要提出高标准。运用你的判断力区分哪些决策至关重要哪些决策可以逆转。当团队成员拥有自主权和责任感时团队会成长得更快效率也会更高。如果最后证明我们确实犯了一点小错浪费了一些时间那就下次加倍努力把这次经验赚回来。