如何做一个称职的基层技术 Leader ？

首先来剖题，这里三个关键字：基层，代表再往下，就是一线程序员了，再没有下级了；技术，这里我狭义定义为程序员，别的领域仅供参考；Leader，也就是组长，或者叫领导，选英文是因为，组长和领导，我都能问出一股“官僚”气味，不想传递这种意思。

如果用选、育、用、留四个字来概括人力资源管理，那技术团队的组建，其实，就是一个“选”字。这个地方，往往实践的时候能发挥很大的主观能动性，在公司来说，其实就是招聘，展开来讲，就整个都是招聘、选人的技巧和标准了，那真的偏题太远，不展开了。

更多想分享的，是“如何当好组长”，也就是 Leader，这么一个话题。

要想当一个 Leader，首先，要具备领导力。所以，关键就要看，领导力到底是什么东西，然后，如何获得或者培养领导力，都搞明白了，那 Leader 怎么当，也就明白了。

错误的理解方式，会把领导力理解成一种权力，有了这种权力，就可以指挥组员做事，自己也就多了一种监督与奖惩的任务。如果这么去认为，就免不了要疑惑，权力的来源是什么，奖惩的资源在哪里？于是，就出现了一种踌躇，老大要任命我为组长啊，任命了我，我就可以给他们分配任务了。

那么什么是正确的理解方式呢？我个人比较认同的是温伯格大叔的全面领导力模型的定义：

所谓领导力，就是创造这样一个环境，每个人都能在其中发挥出更多的能力。《成为技术领导者》温伯格

根据全面领导力模型的定义，我们并不需要一种权力，去发挥自己的领导力，无论我是谁，我都可以想办法去创造这种环境，让团队的每个人，都能发挥出更多的能力。

当一个人，在团队中彰显了自己的领导力，并极为突出的时候，任命其为组长，就是水到渠成的事情，而在比较务实的公司，可能更喜欢选用这种策略去提拔基层的管理者。所以，不要在等待上级的任命了，你并不需要那个。

具体什么样的行为算是在彰显自己的领导力呢？

深刻理解业务问题，程序员其实还是工程师，那工程师就要解决问题，着手之前，首要就是理解问题，只有深刻理解问题，才能行之有效地解决。我工作中，会遇到一些程序员，把理解问题停留在操作步骤层面，产品经理或者业务需求方，会提出一个步骤，一个流程，一个方案，程序员听了，就开始想解决办法，颇有见招拆招的高手风范，其实，恰恰是在被对方牵着鼻子走，还浑然不知，最终因为需求方对技术的理解不深，频繁变动，最终做了很多无用功。理解业务问题，要始终直抵业务目标，综合性、系统性地思考问题，挖掘需求方提出的方案真正的目的是什么。

创新地解决问题，找出更好方案，在深刻理解业务的基础上，就可以考虑更便于实现业务目标的方法，致力于用更有效，更前瞻的方式去实现业务目标。这里有诸多细节，比如，可以找到扩展性更好的实现方案，可以找到复用性更强的方案，可以找到实现更快的方案。主动发现方案缺陷，事先给出解决弥补的方法。

勇于承担责任，对自己经手的业务，要有主人翁意识，业务出问题了，主动站出来解决问题。做到这点看似不难，但是，在比较模糊的情景下，是不是还能做到始终如一，就比较考验人。比如，一个业务三个同事共同负责开发，上线后，爆出问题，三个人都有份，谁应该率先站出来？有三个工作量相似，但是风险大小不同的项目分配到一个团队，你是主动挑责任重大的，还是挑责任轻的？

乐于分享总结，自己成功的经验，尤其是自己失败的教训，是否能够总结，是否能够设计未来规避的办法，并撰写下来，传递给团队成员。通过经验教训总结，可以减少他人犯错机会，并提升团队整体经验值，其实恰恰就是在让团队每个人都发挥出比以往更大的战斗力。

努力去践行这些，就会在团队中建立日益强大的影响力，彰显领导力。归结一个词的话，就是——靠谱。这时小伙伴自然人心所向。任命领导也是水到渠成，就算不任命，凭借着伙伴的信任，你也就能够行使一些组长的权限。

一个基层 Leader 工作的日常

在明确任命了组长后，组长会比未任命时，多出来一些任务。上面的四点，仍然还是要践行的，而且会更深入和更专注地去践行。

除此以外，还有一些别的点。为全组争取更好、更有价值的项目。程序员不光需要工作，还需要成长，只有更具挑战的工作，才能激发程序员的成长，所以组长应该利用自己和上级沟通的机会，为自己的小组争取更具挑战和影响力的项目。

在小组做得很好的时候，要为整个小组争取更多的荣誉和奖励。荣誉和奖励，能形成很好的激励效应，保持小组的战斗力。

培养每一位组员的领导力，其实，这是“分享总结”的一种衍生形式，不但自己具备影响力，还要带领大家一起。只有这样，小组的环境才会更好，每个人能发挥的能力才会更多。

以上，大部分思想，来源于《成为技术领导者》这本书，就是温伯格大叔的名著，当然，完全是我自己的语言，并夹带了一些个人工作感悟和国情和我司司情。请读者睁大眼睛，取其精华，去其糟粕。并祝各位职业生涯顺利成功！

注：文章我自己首发在知乎的，这里是改写了一点。