对于程序员来说，大部分公司都提供了多条职业发展方向：
1. 技术型路线：编程高手、技术专家、架构师
2. 管理型路线：项目经理、部门主管、总裁
3. 复合型路线：技术总监、CTO
4. 特长型路线：销售顾问、培训讲师
这
些路线，看起来很清晰明了。但对大部分26 –
32岁的程序员来说，如何发展，究竟该走哪条路，内心可能都存在彷徨与纠结。技术和管理，有如鱼和熊掌，不可兼得，这是寓言里的警示。但在现实工作中，鱼
和熊掌往往必须兼顾。上面的4条路线中，不少职位可以进一步抽象为技术型领导。如何做一个好的技术型领导呢？下面是我的一些思考。
按需服务
当
官的最高境界，是为人民服务。这句话看起来很虚，仔细想想是句至理名言。但是，作为技术型领导，需要谨慎的不是没有服务精神，而是服务得太热情。
比如一个刚上任的技术领导，接到一个任务时，可能会担心万一同事做不好怎么办？于是将任务中最难的部分，自己加班加点搞定，剩余的部分才交给同事去做。这
种强制性服务，对下属同事来说，并不是一种帮助，而是侵占。会让自己很累，同时让同事缺乏成就感：事情仿佛都是领导做的，自己只是打打杂。
更好的一种处理方式是：先交给同事去做，同时告知如果遇到困难，可以随时讨论，一起解决。这样能让自己更轻松，同时让同事也得到成长。按需服务，而不是一厢情愿的强制性服务，会让团队成长得更好更快。
委托和授权
不
少技术型领导，平时冲锋陷阵惯了，接到任务的第一反应是：如何解决这个任务？甚至10分钟内，大脑里已经把需求拆解成一个个代码段了。这不是一种
有效的领导习惯。更妥当有效的第一反应是：团队中谁最适合完成这个任务？将任务委托出去，授权给合适的同事去负责。任务的拆解分析、时间评估等，信任同
事，让同事反馈给你，而不是亲历亲为。
交代任务本身，而不是实现方法
遇到过一个场景：领导接到一个任务A，想到可以用方法B来实现。于是委托下属去完成方法B. 结果方法B并不能完成任务A, 导致任务A延期。作为领导，交代任务时，一定要如实传递，可以和下属一起讨论实现方法，但切忌不要直接将自己想到的方法当成任务本身分配下去。
参与感、归属感和成就感
流
水线式操作，效率高，但并不适合软件开发行业。软件开发的主体是人，是情感化的程序员。作为领导，不要主动替下属去开各种会议。一个项目早期的需
求讨论、用研分析等，要尽量让开发者参与。参与能让项目组的成员及早地形成团队感。这样，真正开发时，才会当成自己的孩子一样去用心写代码。项目发布后，
这就是整个项目团队成员的荣誉了。否则，领导参加会议，下属只管写代码，流水线式分工，大家就都会有接单思想，有活了就干，没活了上Google
Reader. 缺乏归属感和成就感，做出来的产品绝对好不到哪里去。
信任与尊重
交
代任务时，要信任同事能把事情做好。对于技术型领导来说，交代某些重要任务时，往往会忍不住自己在心里思索预期解决方案，并期望同事的解决方案能
和自己想的八九不离十。当同事的解决方案一旦和自己不同时，这时要特别留意，千万不要将同事的方案直接否定。要懂得尊重，即便自己的解决方案更好，也要委
婉地给出建议，并反思为何当初分配任务时，没有主动去找同事讨论自己的预期方案。
谦虚、坦诚和开放
对于自己懂的，保持谦虚，并尽可能的教给同事，保持开放的心态。
对于自己不懂的，要坦诚直言。不懂装懂，只会让下属看不起。
批评
对下属的批评，话无需多，点到即可。
不吝赞美、懂得欢庆
当下属表现优异时，要在公共场合适当地给予赞美。在周报、邮件里，要多提及团队的成果和优点。当完成重要项目时，适当的聚餐庆祝。在这些点点滴滴中，有时不经意就能培养出团队荣誉感。
原文：http://www.cnblogs.com/tinytiny/archive/2013/02/05/2893323.html