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