engineering-management:基于 GitHub 生态的工程管理资源精选项目

Star1
0
代码
代码
Issues
Pull Requests
项目讨论
Wiki
分析
Star1
0

A collection of inspiring resources related to engineering management and tech leadership

分支1Tags0
文件最后提交记录最后更新时间
.git_hooks
Restrict doctoc to README.md
6 年前
articles
Add lots of articles
9 年前
pictures
Add image
5 年前
.pre-commit-config.yaml
Update pre-commit
8 个月前
LICENSE
Create LICENSE
8 年前
README.md
Tweak article title about project management
1 个月前
glossary.md
Prettier glossary
5 年前

目录

关于本清单

项目：

  • 🧰 ：资源列表
  • 📖 ：书籍
  • 🎞 ：视频/电影片段/电影
  • 🎤 ：幻灯片/演示文稿
  • 🎧 ：播客
  • ⭐️ ：必读

书籍

与其他任何领域相比，管理学领域充斥着大量内容空洞的书籍，这些书的核心观点用一篇100字的文章就能概括。话虽如此，仍有一些优秀的书籍，如下所列。

《赋能：打造应对不确定性的敏捷团队》

📖 《赋能：打造应对不确定性的敏捷团队》 无疑是我最推荐的管理书籍。

这本书让我真正理解了“赋能基层决策”的含义。尤其令我印象深刻的是，作者解释了传统指挥链要求信息上传、决策下达，这种方式效率极低。

书中为管理者提供了帮助团队成员自主决策的实用工具，特别是“深思熟虑的行动”这一概念。还有一个演示文稿 介绍了作者提出的主要理念。

市面上有很多华而不实的管理书籍，但这本书绝非此类。它的叙述引人入胜，解释也简洁明了、切中要害。

你可以在这里找到一个简短的视频摘要。

“没有能力的控制只会导致混乱。”

— 大卫·马凯特，《赋能：打造应对不确定性的敏捷团队》

其他通用类书籍

  • 📖 《组织健康的优势：为什么组织健康比商业中的其他一切都重要（增强版）》，帕特里克·兰西奥尼 著。
    • 人们接受一个信息的唯一方式，是在一段时间内、在各种不同的情境下，最好是从不同的人那里听到它。这就是为什么伟大的领导者将自己视为“首席提醒官”。
    • 级联沟通的最佳方式是面对面的实时交流。员工看到领导者并听到其语气至关重要，能够提出一两个问题也同样重要。
    • 然而，大多数组织之所以不健康，正是因为它们没有做好那些基本的事情，而这些事情更多需要的是纪律、坚持和执行力，而非复杂的技巧或高智商。
  • 📖 《人月神话之外：软件项目经理的幽默故事与实战经验》：“阅读迈克尔·洛普在苹果、Pinterest、Palantir、网景、赛门铁克、Slack 和博兰等公司担任经理期间，从各种时而离奇的经历中提炼出的既有趣又富含深刻教训的故事。其中许多故事最初以原始形式发表在洛普常年受欢迎的博客‘Rands in Repose’上。”
  • 📖 奥伦·艾伦博根，《领导“雪花”：工程经理手册》：包含一些非常棒的内容和具体想法，帮助你从执行者模式转变为管理者模式，对你的管理决策进行“代码审查”，以及如何在不损失质量或可见性的情况下委派任务。
  • 📖 亚当·格兰特，《给予与索取：为什么帮助他人能驱动我们的成功》：“这本书读起来令人愉悦，它打破了贪婪是成功之路的神话。”——罗伯特·萨顿。
  • 📖 肯·布兰查德，《像耶稣一样领导：来自最伟大领导榜样的教训》。
  • 📖 安德鲁·S·格鲁夫，《高产出管理》。英特尔CEO安迪·格鲁夫的里程碑式著作。介绍了许多管理最佳实践，如一对一沟通（1-1）、目标与关键成果法（OKR）。
    • 管理杠杆衡量的是管理者为提高团队产出所采取行动的影响。
    • 你需要像消防部门那样规划。它无法预测下一场火灾会在哪里发生，因此必须打造一支充满活力且高效的团队，能够应对意外情况和任何常规事件。
    • 你一天中的每一小时都应该用于增加你所负责人员的产出或产出价值。
    • 我们应该始终遵循的一个普遍规则是，在生产过程中，在价值最低的阶段发现并修复任何问题。
    • 一个真正有效的指标应该涵盖工作单位的产出，而不仅仅是所涉及的活动。显然，衡量销售人员要看他获得的订单（产出），而不是他打的电话（活动）。
    • 管理者的产出 = 其所在组织的产出 + 在其影响下相邻组织的产出。
    • 联赛排名是按团队计算的，而不是按个人。商业——这不仅指商业贸易，还包括教育事业、政府事务、医疗事业——是一项团队活动。而且，要取得胜利，始终需要团队合作。
    • 你的决策最终取决于你对企业面临的事实和问题的理解程度。这就是为什么信息收集在管理者的生活中如此重要。
    • 不做决策就等同于做出否定决策；没有绿灯就是红灯，整个组织的工作可能会因此停滞。
    • 没有后续跟进的授权就是放任不管。
    • 任何决策都应在最低的胜任级别制定和达成。原因是在这个级别，决策是由最接近实际情况、最了解情况的人做出的。
    • 自信主要来自一种直觉上的认识：没有人会因为做出错误的商业决策、采取不适当的行动或被否决而丧命。
    • 一个成功的目标管理（MBO）系统只需要回答两个问题：1. 我想去哪里？（答案提供了目标。）2. 我将如何调整进度以确保我正朝着目标前进？（答案给了我们里程碑，或关键成果。）
    • 目标管理系统最应该提供的就是聚焦。这只有在我们将目标数量保持在较少水平时才能实现。在实践中，这一点很少做到，而且在这里，和其他地方一样，我们都因为无法说“不”而受害——在这种情况下，是无法对太多目标说“不”。我们必须认识到——并且据此采取行动——如果我们试图关注所有事情，我们就什么也关注不到。几个精心选择的目标会清晰地传达我们对什么说“是”、对什么说“不”——这是目标管理系统要发挥作用所必须具备的。
    • 艾尔弗雷德·斯隆总结了他在通用汽车数十年的经验，他说：“良好的管理在于集中化和分散化的调和。”或者，我们可以说，在于一种平衡行为，以获得响应能力和杠杆作用的最佳组合。
    • 我想提出格鲁夫定律：所有具有共同商业目标的大型组织最终都会采用混合的组织形式。
    • 当一个人没有做好他的工作时，只能有两个原因。这个人要么不能做，要么不愿做；他要么没有能力，要么没有动力。
    • 这个变量就是下属的任务相关成熟度（TRM），它是下属的成就导向程度、承担责任的意愿以及他们的教育、培训和经验的综合体现。
    • 当下属的任务相关成熟度较低时，最有效的方法是提供非常精确和详细的指令，主管告诉下属需要做什么、何时做以及如何做：换句话说，是一种高度结构化的方法。随着下属任务相关成熟度的提高，最有效的风格会从结构化转向更多的沟通、情感支持和鼓励。
    • 教导下属的责任必须由其主管承担，而不是由其组织的内部或外部客户来承担。
    • 在任何时候，你都应该强迫自己评估绩效，而不是潜力。
    • 管理者通常有两种方法来提高下属的个人绩效水平：一是提高动机，即每个人做好工作的愿望；二是提高个人能力，这正是培训的用武之地。
  • 📖 帕特里克·兰西奥尼，《团队的五种机能障碍：一个领导力寓言》。
  • 📖 《工作法则：来自谷歌内部的洞见，将改变你的生活和领导方式》，拉斯洛·博克 著。这本书对谷歌的流程进行了相当有趣的描述，有时略显冗长。
  • 📖 《管理之路》，卡米尔·富尼耶 著。一本非常实用的书，提供了许多脚踏实地的建议。
  • 📖 《团队拓扑学》，ITRevolution出版社出版。探讨了工程部门管理的复杂性，特别是改善团队互动的模式。
  • 📖 彼得·德鲁克的 《卓有成效的管理者》，管理学的开创性著作。讨论了管理的挑战，尤其是知识工作者的管理。提出了有效决策和持续改进组织的原则。
    • 这本书也可以作为超越工程管理、与其他部门协作的基础。

下面还引用了一些其他更专业的书籍。

其他我尚未阅读的书籍：

书籍阅读清单

什么是工程管理？

以下是一些通用资源：

通用管理资源

Tal Bereznitskey 对管理工程师的精彩定义：

招聘有积极性的人。信任他们。对所有事情设定高标准。以身作则。别挡他们的路，让他们成为当天的英雄。就这么简单。

文章

工具

工程管理主题

以下是一系列与工程管理相关的启发性文章。这些文章通常简短精炼，却充满了富有启发性的具体见解。它们塑造了我个人的管理实践，希望也能为你带来启发。

我并非完全认同此处列出的所有观点。事实上，你会发现其中一些文章的看法甚至截然相反。但我相信这些引人深思的资源会在你的管理之路上助你一臂之力。

一对一沟通

反模式

  • 管理的七大致命弊病，Deming博士。相关视频也很精彩。我不一定完全同意其中的所有观点，但Deming仍然是最伟大的管理思想家之一。

偏见

  • 📖 《思考，快与慢》 由Daniel Kahneman所著，2012年出版，现已成为经典之作。它带我们深入了解人类的各种偏见以及判断的局限性。确实是一本令人惊叹的读物。
  • 你不会相信我接下来要告诉你的事，The Oatmeal（漫画），内容关于逆火效应（“当面对与自身信念相悖的证据时，人们可能会拒绝接受证据，反而更加坚定地相信自己的原有信念”，确认偏误 - 维基百科）。

认知偏见不仅会影响招聘……它们还可能对绩效评估、一对一沟通、团队会议，甚至与同事的闲聊产生影响。

头脑风暴

  • 激发全新、更优创意的极致问题，A Smart Bear
    • 以下这些问题能让你跳出局限思维
    • 如果你被迫将价格提高10倍，你需要做些什么来证明这个价格是合理的？
    • 如果我们所有的客户都消失了，我们必须从头开始赢得增长和建立品牌，我们会怎么做？
    • 如果你在任何形式下都永远不被允许提供技术支持，哪些方面必须改变？
    • 如果我们最大的竞争对手复制了我们的每一个功能，我们如何仍然能够胜出？
    • 假设我们被迫在短短两周内发布一个完整的、已完成的（至少是MVP）新功能，这个功能要能让一部分客户感到愉悦和惊喜，我们会怎么做？
    • 如果你被迫以一种完全不同的方式向客户收费，会怎样？
    • 永远不再有同步会议了，会怎样？
    • 如果我们再也不能与客户交谈，我们如何弄清楚该构建什么？
    • 如果你的盈利状况如何不再重要，会怎样？
    • 哪种外部因素有可能扼杀整个公司？

危险的人是只有一个想法的人，因为他会为此战斗到底，甚至牺牲生命。真正的科学研究方式是，你提出很多想法，其中大多数都会是错误的。

— Francis Crick

职业发展与晋升路径

另请查看 charlax/professional-programming 的职业发展部分。

精选的职业晋升阶梯/职业发展矩阵示例：

列表汇总：

相关概念：

变革管理

代码审查

参见我的专业编程部分中关于代码审查的内容

沟通

冲突解决

首席技术官（CTO）、工程副总裁（VPoE）及其他级别

另请参见组织结构部分

  • Martin Casado，Andreessen Horowitz 博客上的Hire a VP of Engineering
    • 工程副总裁最重要的职责是组建工程团队并确立初创公司的工程文化。
    • 因此，称职的工程管理应当能够推动团队采用更务实、渐进式的设计，以便快速获取有用的外部反馈——同时不损害系统的长期通用性。副总裁在此的角色并非产出架构，而是确保渐进式发布成为设计过程中的一项实际要求。
    • 优秀的工程管理往往会给予团队足够的自主权和发挥空间，让他们在推动产品发展的过程中感到愉悦和满足。
  • AVC，VP Engineering Vs CTO
  • Mark Suster，Want to Know the Difference Between a CTO and a VP Engineering?
  • 🎤 CTO vs VP Engineering Balancing Innovation，Bryan Cantrill，Jason Hoffman
  • Will Larson，Your first 90 days as CTO or VP Engineering.
    • 持久的改进依赖于创建能够带来变革的系统，而非执行那些只能产生短暂改善表象的战术性行动。
    • 判断是否确实存在问题且需要立即关注。
    • 旁听客户会议、合作伙伴会议或用户测试。
    • 找到你的业务分析数据以及如何查询这些数据。
    • 旁听现有的面试、入职培训和销售成交电话。
    • 启动工程品牌建设工作。
    • 构建一个小的变更并部署它。
  • The 7 roles of a CTO
    • 高管
    • 代表
    • 人员管理者（有时）
    • 一线开发者（有时）
    • 负责安全与 IT
    • 销售人员
    • 承担一切必要工作
  • Advice for new directors
    • 你的许多工作是培养经理
    • 需要学习的最重要技能：感知你的组织
    • 你需要新的视角
    • 你应该专注于系统
    • 警惕权力带来的扭曲
    • 你的价值取决于你为组织带来的改变。
  • Your CTO Should Actually Be Technical
    • 卓越的技术能力是 CTO/工程副总裁成为真正质量评判者的唯一途径。
    • 这使他们能够做出极具洞察力的权衡决策。
  • 5 Things Founders, Investors and Recruiters Should Know about the CTO role
    • “CTO 的主要工作是确保公司的技术战略服务于其业务战略”——Eric Ries。
    • 作为 CTO，你不能局限于现有框架内工作，因为你的任务是审视这个框架并改进它。
    • CTO 可能会编写代码，但仅限于概念验证（POCs）和原型。
  • What It Really Means to be a Manager, Director, or VP
    • 经理的职责是在获得一定支持的情况下推动结果达成
    • 总监的职责是在很少或没有监督的情况下推动结果达成（“设定目标后即可放手”）
    • 副总裁的职责是制定计划。（不能因为“CEO 批准了计划”就有“免罪符”）

数据组织

  • 在成长期创业公司组建数据团队：一个简短故事
  • 在 Wish 构建分析团队（一个四部分系列文章）
    • 重建数据管道
    • 构建数据仓库
    • 部署商业智能工具
    • 数据工程团队应构建一个允许分析师自主创建其数据管道的系统。
    • 优秀的面试官需要准备灵活的问题，以应对候选人给出的各种信号。
  • 工程师不应编写 ETL：构建高效数据科学部门指南
    • 你可能并没有大数据
    • 没有人喜欢编写和维护数据管道或 ETL。这是行业中最终的“烫手山芋”。
    • 赋予数据科学家端到端的 ETL 所有权
    • 工程师设计新的“乐高积木”，数据科学家则以创造性的方式将其组合起来，从而开展新的数据科学工作。
    • 平台工程师绝对有必要走在数据科学团队的前面
    • 工程师应将自己视为“钢铁侠的裁缝”，打造能够防止数据科学家陷入陷阱（从而产生不可扩展或不可靠解决方案）的“盔甲”。
    • 我们[应该接受]为了速度和自主性而牺牲一定的技术效率

文化

  • 迷宫在老鼠心中 阐述了 Google 的文化如何阻碍其成果和执行力。
    • “这是一种温和的和平时期文化，没有什么值得为之奋斗。”
    • Google 员工几乎没什么产出，因为他们被困在流程的迷宫中。
    • 这种文化过于注重共识（“相互尊重”）和规避风险，从而牺牲了英勇精神或创造价值的想法/赌注。
    • 每个员工的使命不在于服务客户，而在于服务副总裁或某种技术信念/流程。
    • 大多数管理者都是和平时期管理者，缺乏紧迫感。
    • 对于内部技术栈，普遍缺乏谦逊态度。这种“例外论”的错觉导致员工认为他们所做的一切都是完美的。
    • “战略很少被清晰地阐述（那样做会有职业风险）”

决策

你应当避免使用的论证方式——即逻辑谬误 “因为一直都是这么做的。” “因为我们以前试过，没用。” “因为 X 公司在用这个。” “因为 {重要人物} 这么说。”

相反，应基于权衡、约束和机遇进行推理。

—— Gergely Orosz

授权委托

授权委托的 70/10/80 原则：“找到能以你 70% 成功率完成工作的人。再教他们额外 10% 的技能，然后接受 80% 的结果就好。”

交付

开发人员生产力与开发体验（DevEx）

另请参见本页面中的“个人生产力”部分。

多元化与包容性

招聘：

员工手册

员工留存

  • 理论构建及员工流失对软件公司的致命性
    • “当掌握程序理论的程序员团队解散时，程序便宣告死亡。”——Peter Naur，《编程即理论构建》，1985年。
    • 软件是开发团队见解的具体体现。
    • 大多数代码文档在你心中构建起理论后才会变得有用。
    • 程序员构建某一软件准确“理论”的最可靠方法，是亲身参与其最初的编写过程（即“第一代程序员”）。
    • 第二代开发人员过多，第一代开发人员会不堪重负，工作陷入停滞。
    • 第二代开发人员过少，则缺乏团队更新——每一位离开团队的开发人员都可能带来潜在的灾难。
    • 团队稳定性对软件开发至关重要。

问题升级

高管沟通

云成本管理（FinOps）

新任经理

反馈

另请参阅“绩效”部分。

  • 📖 《极度坦诚：成为好老板的惊人秘诀》
  • 📖 Amazon.com:《关键对话：如何高效沟通》（作者：Kerry Patterson）
    • 因此，要想获得我们真正想要的结果，第一步就是要纠正那种认为别人是我们所有麻烦根源的想法。正是我们那种“要是能把那些笨蛋搞定，一切就都好了”的固执信念，让我们无法采取可能促成对话与进展的行动。这也难怪，那些最擅长对话的人往往会颠覆这种逻辑。他们认为，改善“我们”的最佳途径是从“我”开始。
    • 尊重就像空气。只要它存在，没人会去想它。但一旦你把它拿走，它就成了人们唯一能想到的东西。
    • “一支钝铅笔胜过六个聪明脑袋。”不要把你的辛勤工作全凭记忆。如果你已经费了力气完成了一次关键对话，就不要因为相信自己的记忆而浪费掉所有你创造的意义。把结论、决定和任务分配的细节写下来。
  • 《给出批评性反馈入门》
  • 反馈是双向的：工具：试试 Google 的经理反馈调查
  • 负面反馈的反模式
  • 开放式反馈圈（OFC），Padmini Pyapali 提出的绝妙想法。
    • 我们每月聚会一次，围坐在桌旁，当着其他队友的面互相分享反馈。这种聚会将反馈交流从我们所畏惧的半年一次的活动，变成了我们所期待的每月例行仪式。
    • 脆弱孕育信任
  • Simon Sinek：目标应优先于指标
    • 目标固然重要。但达成目标的方式也同样重要。一个两个月后才达成目标的团队，应该比一个以牺牲士气和质量为代价达成目标的团队得到更多奖励。
    • 海豹突击队衡量绩效和信任。他们宁愿团队里有一个绩效中等但高度信任的人，也不愿有一个绩效高但信任度低的人。
    • Simon 的团队进行团队同行评审。一个人分享自己的三大弱点，团队成员可以评论，但只能说感谢，然后他们再分享自己的优点。
  • 我讨厌的经理和他教给我的教训

实践操作

招聘

概述

  • 📖 Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People，作者 Johanna Rothman。一本注重解决方案的书籍。
    • 培训你的面试团队采用有限共识法进行招聘。当团队采用有限共识时，并非每个人都必须同意最终决定，但每个人都应该对特定候选人的适合度感到足够满意，不会阻碍聘用该候选人的决定。
    • “如果拥有否决权的人是我不想留在团队中的人，该怎么办？”答案很简单：在面试过程中，只让你尊重和重视其工作的员工参与。如果某个员工在其技术岗位上表现不佳，就不要让该员工加入面试团队。
    • 确保团队成员以面试外部候选人的同样方式面试内部候选人。
    • 明确招聘更多人员的原因。通过定义问题来制定招聘策略。
    • 有时，招聘经理不聘用某个候选人的主要原因是直觉上觉得此人与团队文化不太契合。但“直觉”并不是不聘用某人的充分理由，因此要训练自己清晰地表达文化契合度方面的差异。
    • 在招聘技术岗位人员时，我个人认为证书并没有太大意义。由于证书所测试的知识是功能性技能的书本知识，因此要确保了解持证人必须做什么来维持其证书，以及该证书对你们工作环境的价值。
    • 内部招聘人员往往过于看重工具和技术专长或高级学术学位，而忽视了功能技能或产品领域经验。
    • 如果你需要做笔记，请用纸笔，切勿使用电脑。原因是使用电脑时，你必须坐在屏幕后面，这会在你和候选人之间造成一道屏障。
    • 承诺无条件晋升不仅有风险，而且是不明智的。公司内部情况可能发生变化；员工的表现可能未达预期；经济形势也可能恶化。
  • eShares 的一份优秀 offer letter 示例。
  • We Hire the Best, Just Like Everyone Else，作者 Jeff Atwood。
  • ⭐️ How to Hire：关于招聘的最佳文章之一。
    • 为优点而雇，而非为无缺点而雇
    • 为发展潜力而雇，而非仅为经验而雇
    • 为实干者而雇，而非空谈者而雇
    • 为学习者而雇，而非专家而雇
    • 为多样性而雇，而非相似性而雇
    • 坚决不雇自负之人
  • ⭐️ The hiring post：Thomas Ptacek 撰写的另一篇非常出色的招聘文章。
  • This is why you never end up hiring good developers
    • 许多面试技巧测试的技能充其量与实际工作无关；
    • 你是想要一个现在就能把工作做好的人；
    • 还是一个足够聪明且有动力、能快速学会工作的人；
    • 你想要一个不断提升自身能力的人；
    • 面试应该是协作式的对话，而非对抗性的审讯；
    • 你也想要一个你乐于与之共事的人；
    • 重要的是要区分“乐于共事”和“乐于一起玩”；
    • 不要雇用混蛋，无论他们有多优秀；
    • 如果你的团队不够多元化，那么你的团队就没有发挥出应有的潜力；
    • 要接受招聘需要很长时间，而且确实非常困难。
  • Engineering Management - Hiring 解释了为什么招聘应是你的首要任务。
  • When we only hire the best means we only hire the trendiest
  • How to Hire，作者 Patty McCord（曾在 Netflix 建立人力资源职能）。
  • Trouble hiring senior engineers? It's probably you。
    • 招聘高级工程师时，你不是在“买”，而是在“卖”。
  • I've been an engineer and a recruiter. Hiring is broken.
  • 🎧 How to Get the Ideal Team Player
  • 6 qualities that make a great engineer
    • 有抱负且意志坚定
    • 习惯性地化繁为简
    • 能快速调试任何问题
    • 帮助他人变得优秀
    • 清楚何为价值所在
    • 富有创造力且态度积极
  • How to hire low experience, high potential people
  • Dumb and gets things done
    • Joel Spolsky 说，理想的程序员是既聪明又能把事情搞定的人。但那些“不算聪明但能把事情搞定”的人呢？
    • 领导者需要推动事情发生。教师需要教学。程序员需要编写代码。这些基本技能是必要的，但还不够。
  • The Quarterback Paradox
    • “Tom Brady 在第六轮被选中，身体素质并不突出，但进入了一个稳定的组织，这让他能够逐步学习和成长。”

招聘：面试

招聘工程经理的具体事项：

招聘：面试问题

招聘：职位发布

招聘：流程

招聘：简历审查

招聘：人才寻访

招聘：带回家作业

招聘：名言

如果你能“严格招聘”，就能“轻松管理”。

Sue Tetzlaff，《员工体验：巅峰绩效的核心指南》

我坚信，我们所做的事情中，没有什么比招聘和培养人才更重要。归根结底，你是在押注于人，而不是策略。

Lawrence Bossidy，通用电气（GE）

我雇佣比我聪明的人，然后我就不挡他们的路。

Lee Iacocca，福特汽车公司

你可以梦想、创造、设计和建造世界上最美好的地方……但这需要人们来实现这个梦想。

Walt Disney

雇佣品格，培训技能。

Peter Schutz，保时捷

在科技行业，关键在于人。找到最优秀的人才，留住他们，培养创新的环境，并帮助找到创新的方法。

Marissa Mayer

我宁愿面试 50 个人却一个不雇，也不愿雇错人。

Jeff Bezos

天赋赢得比赛，但团队合作和智慧赢得冠军。

Michael Jordan，美国前职业篮球运动员

管理问题的最佳解决方案往往是找到合适的人。

Edwin Booz

有人曾经说过，在寻找要雇佣的人时，你要寻找三个品质：正直、智慧和精力。如果你没有第一个，那么另外两个会害了你。你想想，这是真的。如果你雇佣了一个没有[正直]的人，你其实希望他们又笨又懒。

Warren Buffet

你不能只雇佣一双手；整个人总会随之而来。

Peter Drucker

如果你认为雇专业人士来做这项工作很贵，那你就等着雇业余人士吧。

Red Adair

事件预防与响应（值班、故障）

另请参见我的 professional-programming 列表

学习、回顾、事后分析

参见我的 professional-programming 中关于事件响应的部分

引言：

  • “卓越源于对基础的掌握”，文斯·隆巴迪，被认为是 NFL 历史上最优秀的教练之一。

管理风格

引用：

如果你想造一艘船，不要召集人们去收集木头，不要给他们分配任务和工作，而是要教会他们渴望大海的无垠广阔。

——安托万·德·圣-埃克苏佩里

管理是正确地做事；领导是做正确的事。

——彼得·德鲁克

为你工作的人拥有三种资源：时间、精力和在乎。时间是最便宜的，每小时都会补充。精力更昂贵，耗尽后需要大量休息来恢复。一旦“在乎”被耗尽，就永远消失了。

——@leftoblique

会议

指导

思维模式与态度

只有当潮水退去，你才会发现谁在裸泳。 —— 沃伦·巴菲特

@farbood：做正确的事，关乎方向；正确地做事，关乎速度。

@jasonfried：你不能自称为领导者。这取决于其他人。

“在组织中，只有三件事是自然发生的：摩擦、混乱和绩效不佳。其他一切都需要领导力。” —— 彼得·德鲁克

激励

名言：

  • “种树最好的时间是二十年前，其次是现在。”——中国谚语。
  • “船停泊在港口固然安全，但那并非造船的初衷。”——约翰·A·谢德。

为新团队成员或自己办理入职

组织结构

另见 数据组织

  • Martin Fowler 的 团队组织 文章
  • 康威定律，Martin Fowler
    • “任何设计系统（广义定义）的组织，都会产生其结构复制了该组织沟通结构的设计。”，Melvin Conway
  • 团队拓扑中的康威定律
    • 反向或逆康威策略意味着我们应该设计团队（还不是软件）以“匹配”所需的软件架构。
  • Spotify 的 #SquadGoals 失败教训
    • 在这种模式下，工程经理的职责几乎仅限于所管理人员的职业发展。
    • 没有一个人对工程团队的交付负责，也没有人能够在同等责任级别上就工作优先级进行谈判。
    • 自主性需要一致性。公司优先事项必须由领导层定义。自主性并不意味着团队可以随心所欲。
    • 业务部门、部门、团队和经理在沟通组织结构角色和职责方面，比 Spotify 的那些同义词更有效，并且不依附于一种连其创造者都失败了的工作方式。
  • 独立性、自主性与过多的小团队
    • 每个自主团队都应独立产生直接的业务价值，与其他团队没有太多重叠。
    • 团队应能够独立实现其目标（即不依赖其他团队或不受其他团队干扰）。
    • 协调，也称为对齐、沟通、共享路线图、甘特图以及许多其他听起来积极的名称，是自主团队的主要敌人。
  • 🎞 单体与微服务没抓住重点——从团队认知负荷说起，由《团队拓扑》的作者主讲。
  • 软件团队的组织方式（《团队拓扑》书籍摘要）
    • 不应存在组件、库或代码的共享所有权。
    • 如果你有微服务，但仍需等待对多个服务组合进行端到端测试，那么你拥有的是一个分布式单体（分布式单体是指服务中的所有更改都需要更新其他服务）。
    • 使用由业务领域限界上下文定义的软件边界
    • 应不惜一切代价避免仅由具有单一职能专业知识的人员组成的团队。
    • 四种基本团队拓扑：流对齐团队、赋能团队、复杂子系统团队、平台团队。
  • 结构决定战略
    • BAPO：业务（B）应定义架构（A），架构是流程（P）的起点，而组织（O）则基于流程。
    • 大多数公司并非 BAPO，而是 OPAB：将现有组织用作定义便利性驱动流程的基础，进而导致偶然架构的产生。
  • 基础设施平台工程的组织结构和模型：一篇关于如何构建基础设施团队的精彩文章。
    • 描述了4种典型的组织模型及其优缺点：
      • 嵌入基础设施团队的产品组织
      • 共享云工程团队
      • 基础设施组织
      • 基础设施平台组织
    • 结论是，最终专业知识应编码到软件解决方案和自动化中
  • 架构师、反模式与组织混乱
  • 团队拓扑，Martin Fowler 撰写的精彩书籍摘要。
    • 平台的主要好处是减轻流对齐团队的认知负荷
  • 超越合弄制的炒作
  • 组织边界问题：厨师太多还是厨房不够？。包含许多设计组织的有用资源。
  • 我们如何以及为何围绕小团队构建初创公司
  • 错误观念：平台会自动提高生产力
    • 作为产品的平台能提高生产力；“因为我说了算”的平台则不能。
  • 小团队，Posthog 员工手册
  • 基础设施引力与领域工程 主张设立“领域工程”团队的价值。
  • 高绩效技术组织的非主流默认做法
    • 高绩效技术组织的非主流默认做法
    • 不要微型团队
    • 不要黑客马拉松
    • 不要硬性规定“工程时间”
    • 不要过度溺爱工程师的时间
    • 追求健康的人员流动
    • 打破过度专业化
  • 软件的魔力：或者说，是什么让优秀的工程师也能造就优秀的工程组织：发人深省。
    • “事情并非总是从愿景开始，然后利用可用资源去构建那么简单。它们往往是共同或交织出现的，并且事物会不断地向前飞跃。”
    • “在像计算这样的复杂生态系统中，对我们用来创造事物的工具如何运作的深入理解，与我们最终获得的输出质量或创造力之间，似乎存在着某种持续的关系。”
    • “当今许多‘最佳实践’都源自谷歌等历史悠久的互联网公司。然而，基于这些公司的成功而复制它们当前的做法存在一个问题：这些公司中的大多数都找到了近乎无敌的商业模式，基本上是印钞机，因此几乎任何随机制定或选择的组织或管理实践在某种程度上都可能继续‘成功’。”
  • 初创公司工程团队组织

绩效管理

个人生产力

另见：开发者生产力部分

关于一般生产力：

@shreyas：不要被“最佳实践”所迷惑。当某件事被贴上“最佳实践”的标签并进行宣传时，它其实只是平均水平。遵循这些实践只能说明你不会落后，但并不能让你领先。最佳实践实际上是平均实践。

自动化：

关于 GTD：

关于日历：

关于干扰：

  • 如何停止“永远在线”
    • 确定你为什么“永远在线”
    • 检查你的偏见
    • 理性看待你的错失恐惧症（FOMO）
    • 接受真实的自己
    • 停止过度讽刺
    • 慢慢来
    • 寻找其他联系方式
    • 扩展你对互联网的定义
    • 寻找其他新闻网站
    • 使用 RSS 订阅源
    • 找到帮助他人的方式
    • 培养一个爱好
    • 限制为职业用途
    • 保持信念

“做你热爱的事，直到你热爱去做” 我经常想起 @naval 的评论“读你热爱的书，直到你热爱阅读”，这是一个很好的概括。我的经验是，教育一个行动者比激励一个受过教育的人更容易；在开始努力之前，你必须相信自己能做到。—— John Carmack

在任务管理软件方面，我强烈推荐 Things（仅适用于 macOS 和 iOS）。这是一款非常出色的软件，它不会妨碍你，让你能够专注于任务本身。

规划（路线图、目标设定、KPI、OKR 等）

  • 导致开发速度缓慢的十大原因
  • 海尔迈耶准则：一套精心设计的问题，旨在帮助 DARPA 官员深入思考和评估拟议的研究项目。
  • 路线图的基本原理
    • 在持续创新、新市场参与者以及全球疫情等潜在黑天鹅事件的背景下，领导者所能做的最佳选择是制定一个 12–18 个月的战略计划，该计划需与公司的核心方向保持一致。此计划应按季度分解，并假设每个季度内实现目标的信心度会随着时间的推移而下降。
    • 期望组织内的每个团队都能根据这些战略重点制定各自的运营路线图。运营路线图应明确关键举措和里程碑。
  • 如何衡量和提升工程团队的成功
  • “用户故事”无法完整叙事：良好的 sprint 规划需借助里程碑
    • 通过里程碑进行管理
  • 高速增长的例行实践：YouTube 规模化发展的内部视角
    • 规划节奏：6 个月战略规划与 6 周冲刺
    • 战略规划有两个关键产出：(a) “重要事项”列表和 (b) 项目分配矩阵
    • 我们的流程旨在避免“即时性”的临时会议
    • 我们的许多会议都包含一段较长的“自由讨论”时间（即非结构化的多线程讨论时间）
    • 用广播邮件替代汇报会/会议
    • 预读材料（“提前准备，并期望他人也做好准备”）
  • 致产品经理：是时候重新思考企业级初创公司的敏捷方法了
  • 当所有事情都重要却无一进展时
    • 步骤 0：达成存在问题的共识
    • 步骤 1：统一查看所有现有工作
    • 步骤 2：制定并实施项目比较标准
    • 步骤 3：对项目进行排序并承诺执行该顺序
    • 步骤 4：启动工作
    • 步骤 5：识别并解决组织约束
    • 步骤 6：设定明确的终点线（完成定义）
    • 步骤 7：持续推进
  • “大石头、鹅卵石、沙子”理论的实际应用，A Smart Bear
    • 如果你先安排小事，就会没时间做大事。
    • 大石头（Rocks）追求最大化影响力
    • 大石头注意事项：“最大化影响力”比你想象的要难得多
    • 高管做决策，但理想情况下产品经理掌控方向
    • 沙子（Sand）追求最大化吞吐量
    • 注意事项：行政 overhead 会破坏吞吐量
    • 沙子：凭直觉和意愿优先排序，而非数学和指标
    • 自管理团队自行安排沙子的时间
    • 鹅卵石（Pebbles）追求最大化投资回报率（ROI）
    • 注意事项：估算误差对 ROI 的影响可能大得惊人
  • 关键绩效指标信息图
  • 衡量重要的事物，即使你无法完全控制它
  • 领先指标与滞后指标：如何衡量产品 OKR。对该主题的阐述非常清晰，并包含大量参考资料和链接。
    • OKR 理想情况下衡量的是结果（outcome），而非产出（output）。
    • 滞后指标易于识别、反应迟缓且难以改变，是过去的明确结果
    • 领先指标难以发现、能响应团队行动，是未来成功的预测因素
    • 指标是领先还是滞后，取决于团队/具体情境
    • 优先关注领先指标，以避免滞后决策
  • 如何进行规划？
    • 少做一些事情。
    • 自下而上的流程行不通。
    • 规划阶段不是引入新事物的好时机。
    • 你必须提供框架和约束条件。
    • 项目规划存在一个拐点。
    • 不要等到糟糕的想法发展壮大才去终止它。
    • 尽量减少依赖关系。
    • 人员规划不会与你的计划完全匹配。
    • 如果资金不是问题呢？
  • 工程师如何评估产品路线图
    • 路线图是否清晰地与更高级别的公司或产品使命、愿景和战略相连接？
    • 路线图是否直观，能否不用术语就轻松解释清楚？
    • 路线图是以结果为导向还是与客户价值保持一致？
    • 路线图是否具有灵活性或迭代性？
    • 路线图中的举措是否基于证据进行范围界定和优先级排序？
    • 路线图是否识别了主要依赖关系或风险？
    • 路线图是否既具有挑战性又切实可行？
    • 路线图在日后是否易于查阅？
  • 停止凭空创造产品问题；开始解决客户问题
    • “构建陷阱”指的是组织更专注于发布和开发功能，而不是这些功能所产生的实际价值。—— Melissa Perri，《逃离构建陷阱》
    • 当成熟度较低的产品团队开始接触结果目标时，诸如“查询数量”或“邮件发送率”之类的虚荣指标往往会占据主导地位。
    • 当你问“用户希望仪表板有哪些功能”时，你永远不会听到“用户不需要仪表板”这样的答案，除非你非常善于解读言外之意。
    • 项目团队倾向于解决“功能缺失”的问题，而不是“客户无法达成其目标”的问题。
    • 发布 MVP 很快就可能演变成逐步解决有趣的编码问题，而牺牲了对用户体验的可衡量改进。
    • “从客户需求出发反向工作需要大量的努力。但这将为你节省日后更多的工作。”—— 杰夫·贝索斯
    • 实际上，没有任何产品对客户来说是绝对必需的。客户有他们期望达成的结果，而产品可以帮助他们实现这些结果。
  • 为什么大多数产品规划都不尽如人意以及如何改进 对 OKR 提出了发人深省的批评，并提供了一种专注于问题的不同方法。
    • 对 OKR 模型的合理批评：(1) 对于“发展业务”或“提高转化率”这类无限制的目标，其目标本身对于确定工作优先级并非特别有用；(2) 它们缺乏灵活性。
    • 此外：OKR 依赖于整个组织都擅长设定目标，这需要大量的培训。
    • 我的笔记：OKR 确实会导致过度讨论关键结果（KR），而对关键绩效指标（KPI）讨论不足。
    • 他们的方法：只提出并优先处理值得解决的问题，并简单标记为 P0（生存风险）、P1（必须做）、P2（锦上添花）
    • 每个季度用 4 天时间进行公开承诺。
  • 欢迎来到决策室
    • “我们的资源分配是否真的支持我们的成功理论？”
    • “哪些信号能告诉我们我们的理论是否合理，以及我们需要多久才能获得这些信号？”

真理从错误中比从混乱中更容易浮现。 弗朗西斯·培根

目标

  • 有目标，FAST 胜过 SMART：目标应嵌入频繁的讨论中；目标范围应具有挑战性；通过特定指标和里程碑进行衡量；并且对组织中的每个人都保持透明可见。

没有计划的目标只是空想。 安托万·德·圣-埃克苏佩里

OKRs

演讲、设计与公开表达

一些精彩的演示示例：

优先级排序

另请参阅我的 创业资源列表中的优先级排序部分

  • 如何少做事
    • 为待办事项列表排序与只做列表中的首要任务
    • 两个元优先级：（1）维持基本运营，并降低维持成本；（2）将整个路线图精简为每次只做一件事
    • 如何处理失望情绪
    • 尽早且经常说“不”
    • 如何说“不”
    • 如何纠正干扰
    • 保持灵活性：默认采用迭代方式，但也愿意进行投资
  • 优先级排序既是分析问题，也是政治问题
    • 行不通的做法：要求高管团队集体为一长串事项确定优先级
    • 行不通的做法：讲授算法、开发流程和人员短缺问题
    • 行不通的做法：期望电子表格为我们完成优先级排序
    • 有帮助的做法：自上而下明确分配在几个广泛类别上的精力
    • 有帮助的做法：促使每位高管级利益相关者提供其团队需求的非常简短、完全有序的列表
    • 有帮助的做法：每周简要回顾 3-4 个最重要的产品或项目
    • 有帮助的做法：使用“现在/接下来/永不”框架来规划即将做出的选择
    • 有帮助的做法：预先明确哪些类型的工作可以实际外包，并积极招募外部合作伙伴
  • TBM 245：神奇的优先级排序技巧

问题解决

请参阅我的 专业编程部分中关于问题解决的内容

工程流程

@samkottler：再多的流程也无法确保完成正确的工作。

产品管理

另请参阅我的 entrepreneurship-resource repo。

生产与生产力

  • 丰田模式，维基百科
    • 管理决策基于长期理念，即使以牺牲短期财务目标为代价。
    • 创建连续的流程流，使问题浮出水面。
    • 使用“拉动式”系统避免过度生产。
    • 均衡工作负载
    • 建立发现问题就立即停止并解决的文化，确保首次就把质量做对。
    • 标准化的任务和流程是持续改进和员工赋权的基础。
    • 采用可视化管理，使问题无所遁形。
    • 只使用可靠的、经过彻底测试的技术，这些技术能为员工和流程服务。
    • 培养能够透彻理解工作、践行理念并将其传授给他人的领导者。
    • 培养遵循公司理念的优秀人才和团队。
    • 通过挑战和帮助合作伙伴及供应商改进，来尊重您的扩展合作伙伴和供应商网络。
    • 亲自到现场去，以彻底了解情况
    • 通过共识缓慢决策，充分考虑所有选项；快速实施决策
    • 通过不懈的反思（反省）和持续改进（改善），成为学习型组织
  • LinkedIn DPH 框架
    • 目标、信号和指标
    • 开发者角色画像
    • 设计指标时的常见陷阱
    • 他们的示例：开发者构建时间（DBT）、合并后 CI 持续时间、CI 确定性、代码审查者响应时间。
  • 拿破仑技巧：通过推迟事情来提高生产力

项目管理

最终的灵感来自截止日期。 — 诺兰·布什内尔

你必须为自己设定极其激进的截止日期，否则，你会被那些并非真正关键的不必要细节所淹没。如果你还在考虑配色方案和按钮宽度，那你的时间线就太长了。 – 塔拉·维斯瓦纳坦

工作量估算（项目管理）

质量

另请参见我的 professional-programming repo

发布管理

远程团队

RFC（请求评议）

组织规模化

二级经理（2LM）

安全

软技能、情商（EQ）

故事讲述

参见演示文稿

战略

另见：charlax/entrepreneurship-resources 中的战略部分

在此不揣冒昧，分享两个我参与的演示文稿：

调查

人才管理

  • 你的公司需要初级开发人员
    • 初级人才促使团队进行教学、指导与协作
    • 知识发现即创新
    • “ protege 效应”是一种经过充分研究的现象，指当教师需要进行教学时，其自身知识会得到深化。
    • 通才比专才更擅长创新
    • 初级人员意味着心理安全，进而带来更多创新
    • 不招聘初级人员会让你的组织蒙受损失

团队愿景

“从为什么开始”是《高效能人士的七个习惯》中最精彩的章节之一。

技术战略

  • 乔尔·斯波斯基（Joel Spolsky），《永远不要做的事：第一部分》：乔尔阐述了（在他看来）为什么永远不应该重写代码库。
  • 🎤 《选择 boring 技术》，丹·麦金利（Dan McKinley）。
  • 《史蒂夫的谷歌平台咆哮》：亚马逊如何成为一个平台。
  • 《致股东的信》，杰夫·贝索斯（Jeff Bezos）：“第二天意味着停滞。随后是无关紧要。接着是痛苦的、折磨人的衰退。最后是死亡。这就是为什么永远都是第一天。” 这封信包含了太多深刻的见解。“第一天”的核心在于真正以客户为中心、拒绝使用替代指标、拥抱外部趋势以及高速决策。
  • 《预示你的重构将会失败的 5 个危险信号》
  • 《创业环境中的多语言编程》
    • 永远不要因为个人偏好而在现有代码库中引入新的编程语言。软件开发是团队合作。使你的代码语言全球化。团队凝聚力才是最重要的。
    • 你必须对想要替换或补充的编程语言有生产环境经验。
    • 引入新编程语言的决定必须基于非功能需求、度量数据或其他相关论据，而非个人观点。
    • 始终考虑团队和公司，尤其是招聘和团队扩张。
    • 编程语言只是交付软件的工具。不要和你的螺丝刀建立过于紧密的关系。
  • 《技术迁移：Spotify 之道》
    • 无情地进行优先级排序
    • 将迁移产品化：明确责任、测试先行、培训、以价值为导向、了解你的用户（KYC）、游戏化
    • 自动化，自动化，并向更高层抽象迁移！
  • hwayne/awesome-cold-showers：当人们对某些事物过于狂热时，可以看看这个。
  • 《IT 软件工程原则》
  • 《自信领导：工程经理如何避免技术衰退》
    • 向一线贡献者询问更多关于他们所面临挑战的细节
    • 建立知识共享会议，并鼓励分享近期经验
    • 实施副业项目实践
    • 遵循工程师/经理摇摆式职业路径

团队文化

以下被视为经典文献：

culturecodes 是一个公司文化手册的资源库（包含上述手册）。

工程价值观：

  • 工程价值观：致 Medium 工程团队的一封信
    • 个人与职业成长比团队稳定性更重要
    • 人人都是导师；人际连接是激发潜能的途径
    • 优秀团队需要多样性与包容性
    • 优秀的领导者应积极主动且给予支持
    • 优秀的工程师应严谨且坚定
    • 追求卓越是一种美德
  • Lullabot 的工程价值观
    • 以人为本
    • 培养包容性
    • 学习与分享
    • 在完美与完成之间寻求平衡
    • 为未来编写代码
    • 在工作中注入乐趣
  • Figma 的工程价值观
    • 尽早沟通，经常沟通
    • 支持团队成员
    • 精益求精
    • 优先考虑影响力
  • HubSpot 的工程价值观
    • 客户至上
    • complacency 等于失败
    • 像所有者一样思考
    • 快速行动，持续迭代
    • 小团队获胜
    • 保持简单
    • 拥抱组织变革
    • 共同成长
  • Wise 的工程价值观
    • 频繁交付，持续学习，不断迭代，创造影响
    • 保持可替代性——个人独揽责任等于无人负责
    • 快速行动，但要为未来而建
    • 观点鲜明但不固执己见，乐于公开分享
    • 提升标准——为自己，也为团队

团队动态

  • Shields Down，Rands in Repose
    • 各种形式的无聊是导致员工辞职的主要原因之一，但事实上，导致“盾牌”削弱的因素还有很多。
    • 作为领导者，每一刻都是增强或削弱“盾牌”的机会。

培训

  • Great developers are raised, not hired
    • 拿出一部分用于招聘的资金、精力和时间，投入到培养优秀开发人员的指导技能上。
    • 调整面试流程，给那些目前可能还不够优秀，但渴望学习且具备成长型思维的候选人一个机会。
    • 放宽招聘广告中的“硬性要求”，以避免将“ impostors”筛选出去。
  • “Sharing Interesting Stuff”: A simple yet powerful management tool
    • 你的直接下属会在你们会面的前几天，发送一些他们认为值得与你分享的内容（可以是博客文章、书籍章节、视频、播客等），以及他们想到的几个相关问题。
    • 在会面当天，你分享自己对该内容的看法，并尝试回答附带的问题。
    • 下一次会面时，你们互换角色。
  • Introduce Team G Morning Learning Sessions to Coach the Growth Mindset
    • 每天早上会面30分钟。花20分钟学习，10分钟分享所学内容。
  • Your Startup’s Management Training Probably Sucks — Here’s How to Make it Better，First Round Review
    • 人们常常认为自己不喜欢管理培训。但他们真正想表达的是“我不喜欢糟糕的管理培训。”
    • 误区：只培训新经理
    • 零食在厨房很有用，但在领导力课程中没那么大用处。
    • 每个经理培训都应包含的4个主题：
      • 目标设定
      • 人才管理
      • 组织规划
      • 领导力与文化发展

信任

最出色的新想法往往能带来意想不到的益处。因此，要求那些想要尝试新事物的人事先列举出所有益处，是非常不明智的做法。你能做的最好的事情，就是挑选聪明的人，然后相信他们对于哪些事物值得探索的直觉判断。

——保罗·格雷厄姆（Paul Graham）https://twitter.com/paulg/status/1619753568264921089

职业道德与工作/生活平衡

工作坊引导

写作

➡️ 另请参阅我的 professional-programming 列表

另请参阅 RFCs 部分。

其他资源

其他清单

电影

电视节目

Netflix 的 主厨的餐桌（Chef's table） 介绍了几位世界知名主厨。厨房世界与管理领域有许多共通之处。第二季中，我特别推荐第 1 集和第 3 集：

  • Alex Atala 的故事表明，你需要不断自我革新与突破。
  • Dominique Crenn 讲述了她在第一份厨房工作中如何获得工作自主权（当时她基本上只得到菜名、食材清单，在没有厨房培训的情况下就需要发明食谱）。她在自己的厨房中也践行了这一理念。

《办公室（The Office）》是一部关于 dysfunctional 办公室的出色讽刺作品。

保持更新：博客与通讯

以下是我关注的一些博客和通讯。

通讯

博客

  • Hacker News：如果你想及时了解科技领域的动态，这是必读的。时不时也会有一些优质的管理文章。由于它可能会非常耗费时间，我选择订阅精选的顶级文章（RSS 订阅源在此）。

播客

  • FRICTION with Bob Sutton。这个播客自 2017 年起就没有更新过新节目，但它包含一些非常棒的内容。对话精彩，故事丰富。
    • 一部分是组织设计，一部分是“团队疗法”。组织心理学家、斯坦福大学教授 Bob Sutton 再次回归，探讨“摩擦”这一让员工受挫、团队疲惫、组织陷入困境甚至失败的现象。
  • CTO Insights with Katerina Trajchevska。这是一档关于 CTO 所有事务的精彩播客，其中包含与科技领袖如 DHH（Basecamp）、Kent Beck（敏捷宣言）等人的深度对话。
  • The Pragmatic Engineer Podcast with Gergely Orosz 该播客收录了与顶级科技公司资深工程领导者的坦诚对话。话题包括团队扩展、应对高速增长、构建弹性系统以及高效领导等，均以真实的实践经验为基础。

我的其他列表

项目介绍

一系列关于工程管理与技术领导力的启发性资源集锦【此简介由AI生成】

MIT Shell319提交数articlebiasculturedecisionsemployee-handbookengineering-managementleadermanagement非代码
定制我的领域
README
2668.36 K682访问 GitHub