这不是一篇讨喜的文章，至少不会是你常常看到的例如《成为优秀 Tech Lead 的六个建议》令人欢欣鼓舞的那一类。今天我们聊聊 Tech Lead 所面临的不那么轻松的现实问题

程序员一定会有类似的体验：学习技术的过程中首先会经历蜜月期，例如总有新的知识点有待你挖掘，你会觉得它无所不能；也逃不过挫折期，即你会发现技术的边界在哪里，有些业务场景终究是它不擅长的，此时你需要寻找新的解决方案。这未必是坏事，技术边界是一个客观事实，你能够找到它侧面印证了你对旧技术趋于精通，对新技术的征途即将开始。

这几年做 Tech Leader 同样经历了这几个阶段：你会有一个快速的上升期，就像我在上一篇文章《去年我是怎么解决团队问题》里说的那样，不停的遇到问题然后乐此不疲的解决问题——整个过程你会收获颇多，同样是因为对个人来说是这是全新的领域；可后一阶段不尽相同，无力感带来的更多是思考而非答案

被低估的

我想起了书《看板方法：科技企业渐进变革成功之道》（Kanban: Successful Evolutionary Change for Your Technology Business）里的一个真实故事。

2004年10月，微软公司的程序经理扎格斯•杜米特（Dragos Dumitriu）刚刚接管一个部门的工作，团队的主要成员来自印度一家供应商。在微软公司内部，该团队在客户服务上的口碑是最差的，例如他们的变更请求前置时间长达5个月。在经过扎格斯和本书作者对团队工作流程进行一系列优化之后， 团队已经将前置时间减少到平均14天的水平，25天内准时交付的达成率高达98%，处理完成的请求项提升3倍多。

类似的故事在各类书籍、培训中比比皆是，它在暗示如果你能掌握它们传授给你的技能，你就能拥有同样化险为夷的能力——这是对于新人来说最常见的陷阱。

继续回到故事本身，扎格斯能够让团队效率有如此大的提升是非常了不起的事情（即使不是在短时间内）。注意我所说的了不起并非从结果出发，而是指在一个大公司内从设计到执行一系列流程变革。

如果你未曾成为过 Tech Lead，或者未曾有过大厂的工作经历，可能不太能想象的出上述工作的难度。让我简单列举出其中的部分，有些是书中直接给出和推测出的，有的来源于我的经验：

• 虽然你想要做出改进，且上司并不表示反对，但是你需要自己寻找资源
• 跨地域团队沟通成本必然高于本地团队，并且必定存在文化冲突
• 空降领导在还未取得团队完全信任的情况下，需要说服团队接受新的工作模式
• 引入新的流程需要平衡各个业务方的利益
• 要说服上下游接受，哪怕至少尝试新流程
• 该团队的几位前任经理依然是扎格斯的同事，一旦该团队的效能在扎格斯的领导下得到提升，就会显得他们的能力不足

也就是说当我们想推动改善工作时，难点不在于改善方案本身，而在于如何在团队、文化、利益的约束中将方案落地。在越是分工细致的大公司里，上述任务的难度就越高。

你的脑海中肯定早早的有一棵 Tech Lead 所需的技能树，上面挂满了诸如架构、质量、干系人等有待点亮的技能点，但我猜解决上述问题所需的技能多半不在其中。的确这些问题离“交付”、“迭代”甚远，在其他行业同样存在。甚至如果你问我是否赞成把它们放入 Tech Lead 培训中，我的答案也会是否定的，因为一方面很难将这类内容标准化，同一类问题在面对不同的人和团队时解法会不一样；另一方面也无法把它们归纳为纯粹的单项技能予以培养，沟通、情商、经验都包含其中。

但这些琐碎的、无聊的、和代码无关的任务就是 Tech Lead 日常工作的一部分。你以为成为 Tech Lead 之后就可以大展拳脚，例如带着团队挖坑、造轮子、披荆斩棘；殊不知实际上每天等待你的是波澜不惊的代码、无尽会议、还有隔三差五和隔壁团队对线。话说回来，这类工作虽然“基层”却并不可耻。不妨回想一下任意一条在你简历或者述职报告里浓墨重彩的一笔，背后有多少工作仰仗的是非你不可的高精尖技术？大多数是没有难度的苦力活对不对；如果继续拆解，实际投入在编码的精力也不会可观。我们绝大多数人遇到的绝大多数问题，都可以在前人的分享中找到答案。这些答案，好比最后给病人服下的药，而 Tech Lead 的职责是设法让病人把药服下

说白了 Tech Lead 不是甩手掌柜的命，他需要根植一线。同时意味着你要小心那些对系统缺少敬畏之心的人，在他们眼里万物都可以用“不就是XXX”来总结。不用在乎他们真的有两把刷子，还是在嘴上跑火车，几个月后看他们干成了什么就好。

被高估的

此时此刻无论你是打开《哈佛商业评论》网站还是《Coaching for Leaders》播客节目，看到的是琳琅满目的 Tech Lead 工具箱，小到会前如何会前准备 PPT，大到如何引领变革应有尽有，以至于它们很难不让你感受到胜券在握。但你我都知道这是错觉，毕竟专业技能是依靠练习而不是背书习得的。

知识点和现实脱节的原因在于它们并未被转化可执行方案并且固化在你的脑袋中。例如在遇到团队组建初期成员间争锋相对的情况时，也许你并不意外，因为在 Tech Lead 培训中讲师强调过，新团队必定会经过一个震荡期；也许你也意识到应该开始采用某些解决冲突策略介入其中；也许所有的问题统统来自于团队中某一个“坏苹果”——但震荡期的应对措施是什么，那些策略又是什么，我相信此时你的脑海里一片空白。资深的 Tech Lead 同样无法回答这些问题，但我们必须承认在处理团队冲突问题上他们更游刃有余。如果标准答案真的存在并且有机会回顾资深 Tech Lead 解决这类问题的方式，会发现两者多半是相似的。

之所以“信手拈来”重要，是因为问题总是会以教科书之外的形态不规律的出现在你面前。对于大部分不是在开会就是在开会路上的 Tech Lead 而言，在收到讯息的当下，不会留有时间允许你小心翼翼的衡量利弊之后再做决策。

“标准答案”的另一个副作用是它难免让你怀疑直觉，当你的一个想法在材料从未被提及，或者与材料中观点相左时，你应该相信你自己吗？我倾向如此。我们必须承认的一件事是，并不是所有解决方案的正确性都可以通过科学来检验。举一个简单的例子，我认为给团队工作留出一定的空闲时间很重要。这里的空闲时间并不是指因为担心无法任务而将交付日期有意延长的多余时间，而是指程序员可以在上班阶段彻底“不用干活”的时间。之所以打引号是因为我发现即使你有意让程序员慢下节奏来，他们总能给自己“没事找事”，比如做些小工具，比如对代码做一些重构，或者尝试一些新技术，放心这些都是围绕当前工作展开的。即使不存在贡献改进的个体群体也依然可以受益，例如轻松的工作下代码的质量也会比高压情况下的更好。

以上结论完全来自于我的工作经验，其中的道理再简单不过了，所有让软件变得更好的实践都是需要成本的，而且成本中的相当部分一定是时间。我相信即使我没法用科学对它做出证明，你的开发体验多半也会让你在感性上同意我的观点

并不是说理论知识就不重要了，只不过它们成为不了你成长路上的单点依赖。在我看来它们的重要性体现在它们是标准答案，但是是极具理想主义的标准答案：在天时地利人和的簇拥下，方案得以顺利实施并且得以解决。可如果条件并不存在，或者只有部分存在，那么你则需要有的放矢的对标准答案进行调整，结果也不至于太坏。同时如果有机会将你曾经解决问题的办法与之进行对比，你能够从中体会的也会更多

我想起了近期上映电影《奥本海默》里的一段台词：They won’t fear it until they understand it. And they won’t understand it until they’ve used it——是的，知识在你实际运用它之前，它对你一文不值，你还对它一无所知。

被否认的

人类毫无疑问是乐观的，我欣赏这种乐观。但当下乐观似乎演变成了一类政治正确：问题必然存在答案；你务必要积极向上。于是我们读到的文字也无不透露着这类气息：所有的问题都不应成为问题；或者问题之所以成为问题，那是因为你的问题（这便是新自由主义）。

去年我写过一篇有关团队管理的文章《帮助团队成长是唯一的出路》，这不是什么哗众取宠的漂亮话，而是我真心相信如此。我至今依然认为这是 Tech Lead 的主要职责，并且是改善交付的手段之一，但当下我不会认为它是最佳或者说唯一的方式了。因为我们似乎从来没有正面回答过一个问题：如果它的方法不奏效怎么办？或者客气点说，至少对你不奏效怎么办？我们应该如何理解这件事？

一方面我们需要理解所有的这些文字都经过了适度包装，或是让你相信它的权威，或是让你相信自己的潜能，最为重要的是要给予你追随它的理由，比如解决问题的希望；另一方面想当然世界上不存在一劳永逸解决问题的方法，方案总是帮随着必要的前置条件，也许其中的部分在你所遇到的问题里并不成立。

回到本文开头所说的诸如《成为优秀 Tech Lead 的六个建议》这类文章（抱歉这个文章标题是我瞎编的，如有雷同实属巧合），它以一种积极向上的口吻在暗示你：你是问题的瓶颈，你可以做的更好。但事实上，有些问题源自历史包袱，有的是来自于在大环境和行业压力之下，很多问题不是个体可以解决的。作为 TL 你需要知道你权力和能力的边界在哪；你需要区分哪些是 must have，哪些是 nice to have，更重要的是哪些是 will not to have，这样你才能把有限的精力投入到亟需被解决的问题中。在保证交付的目标之下，我越来越意识到不是所有的问题都需要被解决，或是被完美的解决。

例如考虑到不同人的背景、天赋，虽然我们每个人都在尽可能避免评判他人，也不希望被他人评判，但抱歉这无法避免。在具体的工作内容面前，TL 必须要做出选择应该选用哪些人、哪些具有什么样能力的人加入团队才能保证交付的顺利完成。也许对于有的人来说，去填补他与对他期望之间的 gap 只不过是时间上的问题，但有时候我们必须考虑，这里的时间是不是项目能够承受的起的。

抱歉这些话表达的非常不近人情——现实一点，我想说的仅此而已