想象一下，你正在试图弄清楚什么造就了一位伟大的船长。大多数研究都着眼于官方的职位描述、规则手册中写下的规章，或是人们所持有的头衔。但这篇论文决定做些不同的事：它走进了“城镇广场”（一个名为 Dev.to 的社交媒体网站），倾听了水手们自己的声音。他们阅读了 116 篇由软件开发人员撰写的故事，内容是关于在现实世界中领导团队的实际感受。
以下是他们的发现，分解为简单的概念和比喻。
大局观：关键不在于工具，而在于人
如果你认为软件领导者仅仅是一位懂得最复杂数学的超级程序员，那么这项研究告诉你，你关注的是船上错误的部分。
研究人员发现，软件领域的领导力主要关乎“软技能”和人员管理，而非编写代码。
- 比喻：将软件团队想象成一座花园。“技术技能”是种子和土壤。但“领导者”是园丁。园丁不需要最擅长让种子生长（植物自己会生长）；他们需要知道如何浇水、除草、保护植物免受风暴侵袭，并确保它们获得充足的阳光。
- 发现：最受赞誉的领导者并非那些编写代码最多的人；而是那些擅长沟通、倾听、帮助他人成长并保持团队快乐的人。
优秀领导者做什么（“推荐”清单）
研究人员识别出了优秀领导者所做的 103 件事。如果你必须选出前三项，它们是：
- 善于与人相处：培养良好的人际关系和人际交往技能。
- 授权：信任团队去完成任务，并让他们发光发热。
- 作为管理者不断成长：持续学习如何成为一名更好的主管。
“技术”部分：
技术知识重要吗？是的，但它就像工具箱里的一件特殊工具。
- 领导者需要掌握足够的知识来检查工作（例如审查代码），并确保质量上乘。
- 然而，研究发现，在社群眼中，技术技能仅占领导者成功因素的12%。其余的**88%**关乎人员管理、战略和沟通。
糟糕的领导者做什么（“不推荐”清单）
研究人员也考察了领导者不应做的事情。最令人厌恶的行为是什么？微观管理。
- 比喻：微观管理就像一个不愿让孩子自己系鞋带的父母，因为他们觉得孩子会系错。这是对每一个细微动作的 hovering（盘旋监视）。
- 其他坏习惯：傲慢、持有“固定型思维”（拒绝学习）、以被动攻击的方式进行沟通，或营造一种人们不敢发声的有毒环境。
有趣的是，技术失误很少被归咎于领导层。
- 如果一段代码出错了，社群通常不会说：“领导者失败了，因为他们不懂足够的代码。”
- 相反，他们会说：“领导者失败了，因为他们没有倾听团队的意见，”或者“领导者太专横了。”
- 比喻：如果一辆车抛锚了，我们会责怪机械师修不好引擎。但如果这位机械师是个糟糕的老板，对船员大吼大叫并偷走他们的工具，我们会责怪老板，而不是他的扳手技术。
领导力的五个“房间”
研究人员将所有这些行为组织成五个主要类别，就像房子里的五个不同房间：
- 人员管理与培养：客厅。这是你培养团队、指导他们并让他们感到安全的地方。（这是最大的房间）。
- 流程与执行：厨房。这是日常工作发生的地方，领导者在此确保事务运行顺畅且质量上乘。这是唯一一个技术技能被大量使用的房间。
- 沟通与表达：前门。领导者如何与团队、老板和客户交谈。
- 战略愿景：地图室。眺望地平线，决定船只驶向何方。
- 专业与个人成长：健身房。领导者致力于自我提升。
“概念图”
论文最后展示了一张可视化地图（图 4）。将其想象成成为领导者的路线图。
- 它表明，成为伟大软件领导者的道路主要由人际技能（绿色圆圈）铺就。
- 技术技能（橙色圆圈）也存在，但它们只是小小的踏脚石，而非整条道路。
- 地图还突出了“坑洼”（不良行为），如微观管理或傲慢，这些可能会让你的旅程 crashes（崩溃）。
核心结论
这项研究告诉我们，要在软件领域成为伟大的领导者，你不需要是房间里最聪明的程序员。你需要成为房间里最好的园丁。你需要知道如何帮助团队成长，如何为他们扫清道路，以及如何保持环境健康。如果你专注于人和流程，技术上的成功自然会随之而来。
以下是 Coelho 等人所著论文《什么构成了软件领导者？从从业者的社交媒体中识别领导实践》的详细技术总结。
1. 问题陈述
尽管领导力被公认为软件项目成功的关键，但现有研究主要集中于正式角色（如 Scrum Master、项目经理）和预定义框架（如敏捷、Scrum）。这导致在理解以下方面存在显著差距：
- 从业者在日常工作中如何实际体验和展现领导力。
- 在僵化的组织层级之外，构成有效（或无效）领导力的基于实践的非正式行为。
- 理论领导力构建与软件工程实践现实之间的脱节。
作者认为，仅依赖正式角色定义会忽视领导力的“社会影响”方面，并无法捕捉驱动团队绩效的细微的、由从业者主导的行为。
2. 方法论
本研究采用基于目标 - 问题 - 指标（GQM）范式的定性内容分析方法，利用社交媒体数据以最大限度地减少研究者偏差，并捕捉未经请求的从业者观点。
- 数据来源： Dev.to 社区，这是一个面向软件开发人员的全球性开放访问平台。
- 数据收集：
- 初步检索： 使用 Dev.to API，作者检索了标记为
#leadership 的 1,815 篇文章以及 21 个相关关键词（如 #techlead、#teamlead、#engineeringleadership）。
- 筛选过程： 实施了严格的两阶段筛选：
- 自动排除： 移除重复项、非英语文章以及零互动（反应/评论）的文章。
- 人工筛选： 两名研究人员独立分析了 491 篇文章，依据确保深度、与软件工程的相关性以及作者可验证性（简介/专业链接）的标准进行筛选。
- 最终数据集： 选定了 116 篇精选文章（发表于 2017–2024 年）进行分析。
- 分析程序：
- 分析单元： 单篇文章；观察单元： 描述具体行为的文本片段。
- 编码策略：
- 开放式编码： 研究人员提取了 893 个文本片段（893 次提及），未预设代码，保留了从业者的术语。
- 代码统一： 合并相似代码（例如，“以身作则” + “行动引领” → “通过榜样示路”）。
- 分类： 根据行动对象（个人、团队、任务、组织）和时间焦点（日常 vs. 战略），将实践归入五个类别。
- 分类标记： 将实践标记为推荐或不推荐，并进一步分类为管理型或技术型。
- 统计分析： 应用肯德尔 Tau 相关检验以识别主要实践之间的共现模式。
- 可信度： 通过评分者间信度（Cohen's Kappa = 0.879）、研究者三角验证以及开放的复制包来实现。
3. 主要贡献
- 实证基础的特征描述： 直接从从业者话语中推导出的领导实践分类法，超越了正式角色定义，捕捉了新兴行为。
- 概念地图： 对 103 种独特实践（71 种推荐，32 种不推荐）的视觉综合，分为五个类别，区分了管理维度和技术维度。
- 可操作的框架： 为研究人员提供了理论化领导行为的资源，并为从业者/组织提供了基于现实世界社区共识的指导招聘、导师制和培训计划的依据。
- 开放存储库： 所有数据集、编码方案和脚本均公开可用，以确保透明度和可重复性。
4. 主要结果
A. 推荐实践（71 种独特实践）
- 软技能的主导地位： 最频繁的推荐实践是管理型和人际型，而非技术型。
- 前三名： 培养人际技能（占文章的 47.4%）、管理与分配团队工作（39.6%）以及实践管理技能（35.3%）。
- 技术角色： 技术实践仅占推荐提及的 12.6%。当出现时，它们侧重于监督和赋能（例如代码审查、确保质量、技术文档），而非亲手编写代码。
- 类别：
- 人员管理与开发： 提及量最高（31.0%）。
- 流程与执行： 是唯一具有显著技术实践权重的类别（占总提及量的 8.0%）。
- 相关性： 前 10 项推荐实践显示出统计上显著的正相关，表明它们形成了一个连贯的“建议集群”，而非孤立的技巧。
B. 不推荐实践（32 种独特实践）
- 人际失败： 不推荐的行为 overwhelmingly（压倒性地）是管理性和文化性的。
- 前三名： 微观管理（7.7%）、适得其反的工作模式（6.8%）和适得其反的沟通风格（6.0%）。
- 技术缺失： 技术失败占不推荐提及的不到 2%。
- 当技术问题被引为领导失败时，它们与决策过程（例如单方面架构决策）或瓶颈（例如跨团队数据瓶颈）有关，而非代码本身的技术正确性。
- 相关性： 沟通不畅、缺乏公平和过度控制经常同时出现，形成相互关联的负面行为模式。
C. 概念地图发现
- 不对称性： 推荐实践（71 项）比不推荐实践（32 项）多样得多，表明从业者在阐述正面榜样时比阐述反模式时更为详尽。
- “技术加分”假设： 技术能力被视为可信度的先决条件，但并非领导成功的主要驱动力。相反，技术失败很少归因于“领导力”，而是归因于工程执行。
- 核心领导身份： 软件领导力的特征主要是人员管理、战略愿景和沟通，技术参与仅限于质量保证和流程指导。
5. 意义与启示
- 对组织而言： 挑战了将“最佳程序员”晋升为领导角色的传统模式。它表明晋升标准应高度重视人际技能、同理心和战略一致性，而非纯粹的技术产出。
- 对教育而言： 软件工程课程应明确整合专注于冲突解决、授权和心理安全的领导力培训，而不是将这些视为仅在工作中学习的软技能。
- 对从业者而言： 为转型为领导者的开发人员提供了路线图，明确了他们的新职责范围涉及协调团队健康和战略，而不仅仅是编写代码。
- 对研究而言： 验证了社交媒体话语作为实证软件工程研究的可靠数据源，提供了一个窗口，以观察调查和访谈可能错过的“未经请求的”从业者意义构建。
总之，该研究将软件领导力重新定义为一种社会和管理过程，而非技术层级，其中培养健康、自主和协作团队环境的能力是成功的主要决定因素。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。