对于程序员来说，大部分公司都提供了多条职业发展方向：

1. 技术型路线：编程高手、技术专家、架构师
2. 管理型路线：项目经理、部门主管、总裁
3. 复合型路线：技术总监、CTO
4. 特长型路线：销售顾问、培训讲师

这些路线，看起来很清晰明了。但对大部分26 – 32岁的程序员来说，如何发展，究竟该走哪条路，内心可能都存在彷徨与纠结。技术和管理，有如鱼和熊掌，不可兼得，这是寓言里的警示。但在理想任务中，鱼和熊掌往往必须兼顾。上面的4条路线中，不少职位可以进一步笼统为技术型领导。如何做一个好的技术型领导呢？下面是我的一些思考。

按需服务

当官的最高境界，是为人民服务。这句话看起来很虚，细心想想是句至理名言。但是，作为技术型领导，需求谨慎的不是没有服务精神，而是服务得太热情。比如一个刚上任的技术领导，接到一个任务时，可能会担心万一同事做不好怎样办？于是将任务中最难的部分，本人加班加点搞定，剩余的部分才交给同事去做。这种强制性服务，对下属同事来说，并不是一种协助，而是侵占。会让本人很累，同时让同事缺乏成就感：事情仿佛都是领导做的，本人只是打打杂。

更好的一种处理方式是：先交给同事去做，同时告知如果遇到困难，可以随时讨论，一同处理。这样能让本人更轻松，同时让同事也得到成长。按需服务，而不是一厢情愿的强制性服务，会让团队成长得更好更快。

委托和授权

不少技术型领导，平时冲锋陷阵惯了，接到任务的第一反应是：如何处理这个任务？甚至10分钟内，大脑里曾经把需求拆解成一个个代码段了。这不是一种无效的领导习惯。更妥当无效的第一反应是：团队中谁最适合完成这个任务？将任务委托出去，授权给合适的同事去担任。任务的拆解分析、时间评估等，信任同事，让同事反馈给你，而不是亲历亲为。

交代任务本身，而不是实现方法

遇到过一个场景：领导接到一个任务A，想到可以用方法B来实现。于是委托下属去完成方法B. 结果方法B并不能完成任务A, 导致任务A延期。作为领导，交代任务时，一定要照实传递，可以和下属一同讨论实现方法，但切忌不要直接将本人想到的方法当成任务本身分配下去。

参与感、归属感和成就感

流水线式操作，效率高，但并不适合软件开发行业。软件开发的主体是人，是情感化的程序员。作为领导，不要自动替下属去开各种会议。一个项目晚期的需求讨论、用研分析等，要尽量让开发者参与。参与能让项目组的成员及早地构成团队感。这样，真正开发时，才会当成本人的孩子一样去用心写代码。项目发布后，这就是整个项目团队成员的荣誉了。否则，领导参加会议，下属尽管写代码，流水线式分工，大家就都会有接单思想，有活了就干，没活了上Google Reader. 缺乏归属感和成就感，做出来的产品绝对好不到哪里去。

信任与尊重

交代任务时，要信任同事能把事情做好。对于技术型领导来说，交代某些重要任务时，往往会忍不住本人在心里思索预期处理方案，并期望同事的处理方案能和本人想的八九不离十。当同事的处理方案一旦和本人不同时，这时要特别留意，千万不要将同事的方案直接否定。要懂得尊重，即便本人的处理方案更好，也要委婉地给出建议，并反思为何当初分配任务时，没有自动去找同事讨论本人的预期方案。

谦虚、坦诚和开放

对于本人懂的，保持谦虚，并尽可能的教给同事，保持开放的心态。
对于本人不懂的，要坦诚婉言。不懂装懂，只会让下属看不起。

批评

对下属的批评，话无需多，点到即可。

不吝赞誉、懂得欢庆

当下属表现优秀时，要在公共场合适当地给予赞誉。在周报、邮件里，要多提及团队的成果和优点。当完成重要项目时，适当的聚餐庆祝。在这些点点滴滴中，有时不经意就能培养出团队荣誉感。