如何带领资深工程师团队

工程领导者的职责之一是帮助团队成员进行自我发展。培养一支高效且由知识渊博和经验丰富的工程师组成的团队应该是管理者的一个终极目标。但也伴随着一些担忧（我在与工程领导者的1对1会谈中多次被问到这个问题）。

如果那些人比我聪明，我该怎么管好他们？

在这篇文章中，我将分享一些来自《实用工程管理》一书的技巧和资源，这些将帮助你更好地领导一群技术能力强、经验丰富的资深人员，你不能用命令和控制的方式去管束这群人。

根据Wikipedia，以下是“management”一词的来源：

管理这个词源自15世纪的法语动词mesnager，这个词在骑术语言中常指“用手握住马缰”。意大利语的maneggiare（指处理工具或马匹）。西班牙语中的manejar还指“驾驭马匹”。这三个词都源自拉丁语，它们分别是manus（手）和agere（做）。

虽然“手握缰绳，驭马”听起来有点极端，但这倒是映射了刚上任的工程经理的一些默认举动。

管理中的行政部分确实必不可少（比如管理期望、时间安排、资源和成本等）。不过，与有技能的人合作，有更有效的方式，而不是告诉他们做什么以及怎么做。

作为工程负责人，你的工作更注重管理人们的才能、潜力和成长，而不是单纯地管理他们。你可以这样做：

• 通过期望来管理
• 通过问题而不是解决方案来管理
• 围绕目标进行管理
• 依据原则管理

告诉人们做什么和如何做有很多弊端。你通过过度管理，没有充分发挥直接下属的潜力。你也成了一个瓶颈，因为每个人都得等着你的具体指示。

与其发号施令，不如设定一些具体的期望。

• 期待团队能解决具体问题。
• 期待工程师对自己的工作负责（例如，监控服务健康并保持更新）。
• 期待满足特定需求（例如，质量KPI，非功能需求等）。

这样做的时候，你告诉团队期望的结果是什么，而团队需要自己找到正确的做法来实现这一目标。

为了更好地管理你的期望，不要仅仅在目标评价上，而应该扩展你的期望管理实践。

在讨论性能时，你可以考虑一下有三个基本方面，比如：

• 技能
• 作用
• 态度

一个优秀的软件工程师应该具备这些技能的综合。这不仅仅关乎成为一位好的开发者或软件架构师（Hard Skills，如上所述），也不仅仅在于成为一位出色的演讲者或谈判者（Soft Skills）。

硬技能和软技能（例如，沟通技巧）至关重要，但只有在真正发挥其作用时才显得重要（影响）。而团队成员的积极性、开放性和主动性（态度）是最大化这种影响的关键。

想了解更多关于期望管理的内容，可以看看这篇入门文章：期望管理入门

软件工程中一个常见的错误是在我们还未定义要解决的问题之前，就急于寻找解决方案。如果你是管理者，让你最强的员工去实施解决方案，而不是让他们自己找解决方案，你就剥夺了他们寻找最佳解决方案的机会。

在我们生活的这个复杂世界中，第一时间想到的解决方案往往不是最好的。复杂的问题可能有多种定义，但没有一个定义是绝对正确的。一个问题是多个利益相关者共同面对的，每个人心中都有自己的解决方案，而这些利益相关者表达自己偏好的方式各不相同，比如声音最响亮的人，组织图上级别最高的人，或者那些喜欢默默无闻的人。

这就是为什么，在面对任何问题、任务或挑战之前，试着先回答这些问题。

1. 问题是什么？
2. 与这个问题相关的事实有哪些？
3. 问题的根本原因是什么？
4. 这个问题影响了谁？
5. 解决这个问题值得吗？它是否与我们的长期目标和战略相符？
6. 有哪些解决方法？哪些是最佳选择？
7. 执行解决方案。
8. 解决方案是否设定了并达到了成功标准？

让高级工程师也来回答这些问题，会让你得到需要的视角，并帮助更好地理解问题。

这些解决问题的8步来源于我自身的经验以及Don Gause和Gerald Weinberg的精彩故事《灯亮着吗》（Are Your Lights On）所构建的框架。

问题解决框架示例 — 如 FigJam 中的示例模板。

你可以在这里了解更多详情：

在《实用工程管理》中，我常常提到这句话：

技术在产品公司中的作用是帮助客户解决问题。

对于那些凭借专业知识的工程师来说，这尤其关键，他们的专长可以对产品产生巨大的影响。你工作的重要部分是确保他们不仅仅是为利益相关者构建功能，而是成为产品组织中不可替代的一部分。

这意味着最强的工程师们也应参与到发现与交付过程中，并且在上线后也要对自己的工作负责。为了实现这一点，评价他们的工作不应仅看任务完成情况，更要看实际成果。

我在文章《组建一支传教士团队，而非雇佣兵团队》中提到一些细节（见：https://medium.com/build-team-of-missionaries-not-mercenaries-bfb4d193d216）。

建立一支传教士团队，而不是雇佣军团队

驱动团队以成果为导向需要组织已经有一定成熟度。如果你觉得公司目前还不具备这样的条件，你可以尝试通过大多数产品公司都具备的通用因素来明确团队的目标：

• 增长
• 扩大
• 客户满意
• 开支

更多详情请参阅这篇文章：任何产品成功的四大要素

一个公司的使命和愿景通常是比较高层次的，不容易转化为具体的行动和决定。为了保持步调一致，公司可以培养一种以原则为基础的领导风格。原则的概念作为指导方针，帮助决策并追求公司的战略方向。

原则为团队提供一致性和自主权。即使有强大的软件工程师，解决问题的方法也多种多样。原则指导决策，无需持续监督，让团队自主做出选择。比如，在考虑增加API的安全层时，苹果公司的“隐私是一项基本的人权”原则会让这个决定变得非常明确。相比之下，Facebook的“快速行动”原则可能会引发更多的讨论。

虽然你的团队应该专注于如何实现某个挑战，你的原则应该告诉他们工作中最重要的事情是什么。

这里有一些行业准则的例子。

• Google 的 “专注于用户，一切将随之而来”：强调以用户为中心的设计，这一原则激励软件工程师优先考虑用户体验，确保产品直观且易于访问。
• Amazon 的 “逆向工作”：此原则鼓励工程师从最终用户的视角出发，向后工作以确保产品符合预期目标。
• Netflix 的 “高度一致，松散协作”：原则是拥有目标一致但执行上相对独立的团队，可以激励软件工程师既能独立工作又能为整体目标作贡献。

如果你的组织还没有明确的原则，不要让这阻碍你为团队制定它们。在小型公司中，这是你以身作则，并影响整个组织的机会。

《实战工程管理》这本书在其中探讨了指导原则 — 团队指南这篇文章：https://www.practicalengineering.management/p/principles-guidelines-for-your-team。

不管你的团队中工程师们多么出色，作为领导者，你还是需要遵循一些通用的原则。

《加速》这本书指出五个关键特点，这些特点是高效团队领导者的标志：

• 远见卓识的,
• 激励人心的沟通,
• 智力启发,
• 支持性的领导方式,
• 个人肯定。

了解这些特质，看看它们如何能提升你的领导技能。点击这里了解更多详情。

在实践工程管理中经常被提及——如果你只能选一个领导技巧来和你的团队相处，那就选择一对一（1:1）。

1对1会议，也就是一对一会议，通常指的是：

注：此处的“1:1 meetings”可以保留为“1对1会议”或直接翻译为“一对一会议”，以保持语义清晰。根据要求，对于特定术语，保持原文或翻译均可，但此处建议直接翻译以增加理解度。

• 你把这些抽象的概念变得具体化。
• 你支持你的团队发挥他们的潜力，并在职业上取得成功。
• 你将公司的战略目标转化为日常行动。
• 你促进公司的文化发展。

开始进行你的一对一会议可能颇具挑战性。你需要确保这些会议有结构和连贯性，并确保它们对你的团队成员有益。在《实践工程管理》这本书中，你可以找到关于如何进行这些会议的核心原则和焦点领域的相关资料。

您可以在这里探索这些资源：

• 1:1 — 领导者的必备工具
• （付费内容）工程领导者的一对一会谈前10次

这篇文章中，我分享了一些工具和技巧，帮助工程领导者应对他们在角色中遇到的挑战。希望这能帮助你在你的角色中成功地扮演这个角色并获得成就感！

这份指南旨在帮助你领导资深软件工程师，他们在某些方面可能比你更有经验。我的目标是帮助工程领导者将好点子变为现实。

在practicalengineering.management上探索更多内容。您将找到实用策略。加入这个有影响力的领导者社区，以弥合灵感与实施之间的差距，通过切实可行的步骤激励您的团队，提升信任，从而推动实际成果。

如果你有任何挑战想要讨论，可以随时通过邮件联系我，邮箱是mirek@practicalengineering.management。