Errong Leng

从写代码到定义使命：一次技术负责人的思考 今天，作为一名技术负责人（Tech Lead），我参加了一次领导力培训。这次培训出乎意料地改变了我对团队、责任以及影响力的理解。 我们并没有讨论技术框架、系统架构图，或者性能优化。 相反，我们聚焦在一个更根本的问题上： 学会不断追问“为什么” 作为工程师，我们习惯于问 “怎么做” ： 这个功能怎么实现？ 怎么优化性能？ 这个问题怎么修？ 但领导力，往往始于另一个问题： 为什么这个团队存在？ 如果没有清晰的“为什么”，团队很容易迷失方向，工作变成被动响应，决策也会显得零散而割裂。 一句话使命（Single Statement）框架 培训中介绍了一个非常简单却极具力量的方式，用一句话来定义团队的使命： 为了 <行动>，服务 <人>，从而带来 <影响>。 这个结构迫使我们直面本质： 行动（Action） —— 我们具体在做什么？ 人（People） —— 我们为谁而做？ 影响（Impact） —— 我们真正想带来什么改变？ 这对技术负责人的意义 当成为 Tech Lead 之后，角色已经不再只是“写好代码”。 我们需要对以下内容负责： 使命（Purpose） —— 团队存在的意义 领域（Domain） —— 我们负责什么，不负责什么 责任（Accountability） —— 决策和结果如何被承担 一句清晰的使命宣言，就像团队的指南针： 帮助团队做优先级判断 对齐技术决策 让团队成员在没有指令的情况下也能做出正确选择 向优秀使命学习 培训中我们也参考了一些知名公司的使命表达。 一个经典的例子是： “整合全球信息，使人人皆可访问并从中受益。”   行动清晰，对象明确，影响直接。 它解释了 为什么 Google 会去做它所做的一切，而不需要列出任何具体产品。 回到我自己的角色 这次培训让我再次意识到：领导力的核心不是控制，而是清晰。 当团队真正理解自己的使命时： 责任感会自然提升 协作会更加顺畅 决策能力会从 Tech Lead 扩展到整个团队 接下来...

From Building Software to Defining Purpose: A Tech Lead Reflection Today, as a tech lead, I joined a leadership training that unexpectedly shifted how I think about teams, ownership, and impact. We didn’t talk about frameworks, architecture diagrams, or performance tuning. Instead, we focused on something much more fundamental: Learning to Ask “Why” As engineers, we are trained to ask how : How do we implement this? How do we optimize it? How do we fix it? But leadership starts with a different question: Why does this team exist? Without a clear “why,” teams drift. Work becomes reactive. Decisions feel disconnected. The Single Statement Framework The training introduced a simple but powerful way to define a team’s purpose using one sentence: To <ACTION> for <PEOPLE> so that <IMPACT>. This structure forces clarity. Action — What do we actively do? People — Who do we serve? Impact — What meaningful change do we create...