/ 未分类 / 639 views

转载-如何做一个好的技术型领导

原文网址: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. 缺乏归属感和成就感,做出来的产品绝对好不到哪里去。

信任与尊重

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

谦虚、坦诚和开放

对于自己懂的,保持谦虚,并尽可能的教给同事,保持开放的心态。

对于自己不懂的,要坦诚直言。不懂装懂,只会让下属看不起。

批评

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

不吝赞美、懂得欢庆

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

1小时编写一个支持七牛上传的 markdown 客户端3(打包发布篇)
1小时编写一个支持七牛上传的 markdown 客户端3(打包发布篇)
1小时编写一个支持七牛上传的 markdown 客户端2(代码优化篇)
1小时编写一个支持七牛上传的 markdown 客户端2(代码优化篇)
1小时编写一个支持七牛上传的 markdown 客户端1(技术实现篇)
1小时编写一个支持七牛上传的 markdown 客户端1(技术实现篇)
从 wordpress 转移到 hexo
从 wordpress 转移到 hexo
移动端重构系列
移动端重构系列
漂亮、简洁的在线编辑器 Quill
漂亮、简洁的在线编辑器 Quill

0

  1. This post has no comment yet

Leave a Reply