一级经理 — 技术主管、工程经理、产品经理或团队主管 — 在公司中担任最关键的角色。这句话是整个实用工程管理理念的基础。

他们具有挑战性的工作是将实践经验与战略思维相结合。他们结合了有关产品、业务和技术的知识。他们将长期目标转化为日常任务。没有人比客户更亲近。他们有能力直接向他们提供功能。

组织的成功非常直接地取决于这些一级人事经理。然而，在软件工程行业又一个充满挑战的一年里，越来越多的公司决定扁平化他们的组织，减少工程经理角色或将其转变为更多实践职位（工程经理 -> 技术领导者）。

为什么？

除了冷酷的成本计算、减少干扰和缩小公司的关注点外，有时工程经理根本不够好。这是一个残酷的事实，但如果他们的角色只是分配任务、下达命令和阅读报告，那可能比没有这样的管理者带来更大的伤害。

让我们仔细看看好管理者和坏管理者之间的区别，以及我们今天可以做些什么来成为更好的软件工程领导者。

工程经理的角色

在一个健康的技术组织中，工程不是成本中心，而是利润中心。这意味着是产品（客户需求）推动了技术的发展，而技术使产品成为可能。

工程经理的职责是确保产品环境影响技术，并确保技术的构建方式能够促进进一步的产品开发 — 其增长或扩展。

但是，如果工程经理是唯一了解产品环境并通过自上而下的订单控制工程团队的人，我们最终会陷入这样的情况：团队要么只编写代码（最坏的情况）要么此时此地构建产品功能（更好的情况，但仍然很糟糕）。

授权工程经理的作用是确保人们确切地知道他们要解决的问题，因此产品环境是广为人知的。这些人拥有以最佳方式解决这些问题的技能、工具和流程。

好经理和坏经理有什么区别？

糟糕的经理：

• 微观管理 — 他们只分配任务，不允许集体决策。
• 不要为产品发现做出贡献 — 他们不会试图了解要解决的真正问题。
• 不要管理期望 — 他们不专注于路线修正，不培养团队的技能，也不寻找对员工最有影响力的计划。
• 他们是守门人，而不是推动者——他们不是寻找解决方案，而是 “保护” 团队，直到他们得到 100% 的要求。

优秀的管理者：

• 管理人才 — 挑战和培养工程师，或通过优秀招聘填补空缺。
• 管理期望 — 让团队专注于结果，而不是输入。
• 管理人员 — 让人们感到受到重视、积极性和工作效率。
• 管理影响 — 将人员分配到尽可能好的计划中。
• 管理产品 — 深入了解他们试图解决的问题，以便构建最佳解决方案。
• 管理技术 — 维护技术债务、改善开发人员体验、使技术堆栈与产品战略保持一致、设置技术标准、KPI 或 SLI/SLO 等。

自上而下还是居中外？

有两种类型的领导方法——自上而下和中间向外。

许多工程经理坚持自上而下的领导风格太久了。最初，它对于引导团队或流程或在危机时期发挥领导作用可能很有效。但是，如果工程经理是唯一拥有数据并做出所有决策的人，而团队被期望仅执行他们的指令，那么这并不是管理科技界团队的有效方式。

自上而下的方法不允许队友思考。他们缺乏工作背景，也不被邀请进行协作思考。这在高级软件工程师的环境中尤其危险，他们可能比他们的领导更了解这项技术。对他们来说，成为自上而下的领导者会剥夺团队所拥有的所有经验和知识。

自上而下的方法也会导致领导者的认知超负荷，因为领导者必须掌控一切。这种持续的紧迫性和对他们环境的高度详细理解的需求导致他们的工作和决策质量下降。

但还有一种不同的工作方式 — 通过中心导向的领导方法，领导者可以通过让经验丰富的团队成员参与决策来激发集体智慧并培养更多的创造力。

中心导向型领导者不注重协调（人员、决策、数据），而是注重沟通、促进和知识共享。如果您希望以这种方式工作，您必须建立相互信任并有效地授权。这并不意味着减少工作（委派和忘记），而是更聪明地工作。

中间导向型领导者创造并维护一个环境，让人们确切地知道他们正在解决什么问题——他们拥有所有必要的数据和产品环境，并且可以设计自己的解决方案。然后，领导者可以将从这些本地解决方案中学到的知识综合成系统范围的知识，然后在整个组织内共享。

文章的备忘单：

管理不是关于执行，而是关于改进和成长

工程经理的角色不是控制执行，而是不断改进情况，以便团队的影响力随着时间的推移而增长。

执行

糟糕的管理者注重执行力。他们此时此地管理这种情况。任务进来出出。他们的工作主要是在隐藏的假设下安排时间，即事情将永远保持原样。

但这是一种错觉，尤其是在“唯一不变的是变化”的科技组织中。我们的软件变得越来越复杂，质量下降，并且变得更加难以维护。组织不断发展 — 人员来来去去，优先事项发生变化，业务环境不断进步。

组织熵和惰性是强大的破坏性力量，作为一名只专注于执行的工程领导者，您的影响力不仅会保持平稳，而且会随着时间的推移而下降。

提高

更具影响力的工程领导者专注于随着时间的推移变得更好。

以下是一些示例：

• 在开发过程中改进技术堆栈 — 在许多组织中，团队有“10-20% 的时间专门用于技术改进”。作为工程领导者，您需要设定目标、KPI 或非功能性需求，并期望每个产品开发任务也有助于实现这些目标。
• 成长的团队成员 — 每个团队成员都有自己的成长目标，例如设置为 SMART 目标。随着时间的推移，人们会获得各种不同的任务、培训机会和更大的责任。他们可以攀登职业阶梯。
• 通过减少来改进 — 我们不仅通过添加新的东西来改进事物，还通过简化或减少来改进事物。这对我们的大脑来说并不总是显而易见的。

复合

复利就像改进，但不同的是，我们专注于正确的事情。这里的领导者仍然不断改进他们的技术栈，并专注于发展团队的专业知识。但是，目标、KPI 和计划不是即兴创作（例如，我们设定 SMART 目标，因为我们的人力资源部门告诉我们这样做）或过度优化的。

因此，除了在工作中积极应用改进之外，我们还必须与反馈机制合作，以评估我们是否投资于正确的事情，随着时间的推移，我们越来越接近预期的结果。

这里有一些工具和技术，它们不仅可以帮助我们改进，而且随着时间的推移可以增强我们的影响。

建立坦诚反馈的文化 — 作为领导者，您的工作是为自己设置多个信息流。如果人们愿意与您分享反馈——他们的挣扎、想法和想法，您将可以访问“基本现实”。它将帮助您以定性方式验证您提供的改进是否使事情变得更好。

更加以数据为导向 — 除了定性反馈之外，您还应该收集数字数据，这些数据将告诉您更多关于工作进度、预期结果等的信息。一些示例可以是：

• DORA 指标 — 部署频率、变更提前期、变更失败率和平均恢复时间 （MTTR）
• 基本的行为分析，以便您了解客户如何使用您的产品
• 您为您的特定需求构建的数据仪表板，例如，跟踪团队的目标

更好地了解摆在你面前的问题 — 有时，当我们有一项产品任务要处理时，我们只是直接进入实施，没有进行任何额外的思考。至少在大型战略项目中，我鼓励您重新构建问题，以便您有充分的理解。如果你这样做，就会更容易选择正确的方法 — 解决方案、架构和其他资源，以有效地解决这些问题。

保持一致 — 复利意味着在较长时间内改进事情。这就是为什么您应该定期验证您的目标、胜利和干扰因素。我建议每周写一篇领导者日记，写下这些事情来验证你的成果并最大限度地发挥你的工作影响。

制定一个计划 — 复合不是即兴创作，而是一套连贯的行动，作为对摆在你面前的战略问题的回应。如果你想制定这样的计划，没有比理查德·鲁梅尔特 （Richard Rumelt） 的《好策略/坏策略》更好的知识来源了。根据它，一个好的策略的关键要素是：

• 诊断 — 涉及了解当前情况并确定组织面临的关键挑战。
• 指导政策 — 涉及制定组织将采取的应对挑战的总体方法。
• 连贯行动 — 涉及采取一系列旨在实施指导政策的协调行动。

在实践中，我使用 1 对 1 收集的所有反馈绘制板（使用 Miro 或 FigJam 工具），并与工程师、领导者、高层管理人员以及产品和业务利益相关者进行头脑风暴讨论。然后我用 Rumelt 的框架对其进行分类，并根据这个结果，我绘制了 6-18 个月的计划。

在动态的工程领导力环境中，单纯管理和真正领导之间的区别从未如此重要。本文探讨了在当今快节奏的技术环境中成为有效的工程领导者的本质。

常见问答(FAQ)

1.什么是软件工程领导者的核心职责？
软件工程领导者主要负责团队管理、项目规划与分配、代码质量监督以及技术指导。确保项目按时交付、团队成员成长，并维持高效的协作环境是其关键任务。

2.软件工程领导者需要具备哪些核心技能？
必备技能包括技术专长、沟通能力、团队管理、项目管理、问题解决能力和冲突管理。具备这些技能能帮助领导者更好地支持团队并推动项目成功。

3.如何在技术和管理之间找到平衡？
软件工程领导者需要根据项目阶段分配时间。初期需要更多的技术参与，而项目中后期则应关注管理和监督，确保整个项目和团队进展顺利。

4.如何提升团队士气和生产力？
提供清晰的目标、透明的沟通、适当的激励和技能培训可以有效提升士气。同时，创建开放的反馈环境，帮助成员不断改进与成长。

5.如何帮助团队成员提高技术能力？
鼓励团队参加技术培训、分享学习资源、组织内部知识分享会，并提供项目实践机会。支持成员在日常工作中应用新技术与方法也是一种有效提升方式。