不知不觉间，在互联网软件开发这个行当，已经做了快 15 年了。偶尔和兄弟们酒酣畅聊，回想起当初懵懵懂懂闯进软件开发这个职业，才发现开始总是比后来单纯和美好！
做个好的软件工程师
虽然我职业身份一直自称是互联网软件工程师，但事实上我最早从事的，是芯片行业。
2006 年到 2008 年，我课余做了一年多的芯片工具链开发，独自完成了修改 GDB 调试器支持一种新体系结构的 CPU。初生牛犊非常虎，在各种 mailinglist 里灌水，现在搜一下，还能找到：
那时候让我想未来，我觉得我应该是希望成为 Sun Chan 那样，20多年在编译器这个行当里，经历过 MIPS、SGI、Intel 这些传奇公司，经历过日新月异的 CPU 技术变革，还在应对手机SoC 和多核的挑战。
那时候的我，只想做一个好的软件工程师。
认识杠杆
在真正进入职场以后，我才发现：当你有更大的野心时，只作一个好的软件工程师是不够的。
当我的领导第一次告诉我，公司里 C++ 工程师的平均日编码量大约在 100 行左右时，我是有点惊讶的。后来我查阅了各种数据，发现这还真是一个产业界的客观水平。后来想想这不难理解，因为你不可能投入 100% 的时间在开发工作上。有需求沟通，有调研和设计，有讨论和评审，有修改和调试，有值班和运维，等等等等。
只用代码量来衡量一个人，是愚蠢的。
但代码量说明了，一个人的单打独斗，很难做什么大事。
我的师兄徐宥在一篇博客中给出了他观察到的模型：
做出 MapReduce 框架的和写琐碎 MapReduce 程序的工程师之间的差距并不是他们的工具和编程效率，也往往不是教育背景或者经验，而是他们各自的杠杆：所带领的团队。
在企业中，表现优异的员工，是容易获得杠杆的。
可能先从带实习生开始，然后做新员工的 mentor，然后慢慢有自己的小团队。然后就是传统的管理工作，决策、计划、分工、控制，可能也会做一些战略和激励，与其他行业的管理工作没有本质不同。
但回顾我十几年的实践过程，又模模糊糊觉得这些不太足够。
像师兄那篇文章中讲的那样，我也尝试总结一下自己积累的管理模型，比如扩展一下师兄的杠杆理论，我把它叫做“技术领导的杠杆和支点”。
杠杆和支点模型
其实团队杠杆理论有很多人讨论，但大部分讨论都是求诸于外，比如怎么分工、怎么授权、怎么激励，最终是提升效益。这不是我想讨论的部分，因为这和其它类型团队的管理方法没什么不同。
我想讨论的是技术领导的求诸于内。
大部分技术团队的领导，都是技术专家出身。但我观察到一些技术专家在成为领导之后，反而会选择弱化自己的专长，甚至停止了技术思考，变成“需求和问题驱动型领导”。只有提到他面前的需求，或者执行中出现了问题，才能看到他的工作。
还有更多的技术领导，将所有工作全部分派授权下去，不再做任何具体的工作。这可能因为实在太忙没时间做到；可能因为累了想躺一躺；可能因为环境的影响，例如“是否还需要写代码”成为衡量你是否仍是牛马的标志；也可能因为对具体工作就没有那么的热爱。
我不否认这样的技术领导依然有可能做得很成功，但这样做的技术专家放弃了一个自己最大的竞争优势：技术上的专业性。
技术的专业性可以作为非常有效的杠杆效应放大器。
在解决需求和问题的同时，趁机对系统做一些治理；在短期目标与长期不一致时，做更优雅的妥协；在团队厌倦于平庸的工作时，提出更有挑战的目标；在对代码屎山忍无可忍时，做更有远见、更有可持续性的重构设计；在无人拍板而内耗时，做大胆的决策，并往往做对；与大家讨论时，不以地位而是靠逻辑来说服人。这样的团队，能够更容易地形成技术共识，达成对目标和路径的清晰理解，也更有生产力。
当你做每件事时，不仅从技术之外，还能从技术本身去思考它对现在的作用，对未来的意义，对每个参与者的影响，并能够据此去调整自己的决策。这本身就是一种比较优势，技术领导不要轻易放弃这种优势。
解决 hard and dirty work 可以抬高杠杆的支点。
我也曾见过这样的技术领导，系统设计理念非常先进，时髦的概念都能包含，目标更是远大宏观。但遇到问题的时候，他总会说，你们再试试，你们再想想，你们再调研一下。最终搞得团队放弃也不敢，继续干又干不下去，有苦而不敢言。
客观来说，有时候这些主张未必是错的，但可能团队不具备这样的能力。最近有人常说：“世界就是一个巨大的草台班子。”那认识不到自己的团队是草台班子，是领导的责任；解决不了这样的困难，也意味着领导没有认识到自己的草台本质。
没有什么能比亲手去解决阻塞团队的问题而实现自己吹过的牛皮，更能增强团队对一个技术领导的信心；没有什么能比亲自下场去干脏活累活，更能赢得团队对你的爱戴。
《Team Geek》书里有这样的管理建议：
Delegate, but get your hands dirty.
授权，但仍然亲手做些事。
不过如何在授权和自己做事之间平衡，依然是一个技术领导要长期考虑的问题。拿我自己来说，虽然最近几年基本还能保持一万行每年的亲手编码工作，但去年就没有做到。因为去年我花了太多时间在学习 LLM 的论文，看各种实现的代码。AI 的爆发让很多人措手不及，我也是其中一个，但我不想因为自己的认知限制团队的上限。
这就是我的“杠杆和支点模型”，希望对你也有些用。