珠的自白:11 领导需要比下属更懂技术吗

112453625e1fc62586e948.png(PNG 图像,639x437 像素)

领导需要比下属更懂技术吗?

领导必须更懂技术吗?这是个问题. 做了领导以后,因为工作的关系,许多人都不那么熟悉基础的技术了,结果自己心里没底,更怕遇到问题时在下属面前丢脸. 所以,有些人选择了双管齐下–既不放弃领导的工作,又不放弃原有的技能,结果疲惫不堪. 还有人干脆选择不当领导了,因为有手艺,才有安全感.

这个问题也困扰过我,而且始终找不到”合理”的答案,最终还要靠亲身的工作经验来解答. 所以在正式回答这个问题之前,让我先讲讲自己的亲身经历.

在我刚工作的时候,业界使用的Java(当时不少人还用的J2SE这种”专业”的说法)的版本是1.4.2,而Java 5.0的版本已经推出了,并且Sun做了大量的工作,宣传Java 5.0的各种好处. 我作为充满好奇的职场新人,当然也鹦鹉学舌地”明白”了不少,比如范型,比如改进的for循环等等. 相比之下,实际项目中老版本代码太多的”陋习”已经让我跃跃欲试,要大修大改一把了. 不过,要做到这一点,我首先需要获得项目经历的许可. 于是我仔细准备了几天,凑齐了一些自认为有说服力的资料,然后跑去跟项目经理建议,我们应该升级到5.0版本.

我永远都记得他当时的反应:先是一愣,然后说, “但是我们已经很熟悉1.4.2了呀,而且这个系统长期以来都是跑在1.4.2上面的,很稳定. 你建议的这些特性,并没有太多实际的好处. “

听了这话我想,他虽然做过不少项目,但脑子已经不够更新了,一直停留在1.4.2的时代了,这就是他否定我的建议的根本原因.

“不过,如果你有兴趣,也可以先做一个仔细的调研,然后模拟环境测试一下,看看5.0到底能不能跑. “

既然他最后给我留了个希望的口子,我还是奋力去准备争取,耐着性子尽可能详细地做了试验. 果然,我发现直接升级到5.0有问题,有个依赖的第三方库会产生兼容问题. 当然,最终升级方案还是通过了,系统也有惊无险地升级成功. 但我回头想想,却不得不佩服项目经理的保守:如果冒失升级上去,估计生产系统就不转了. 更让我困惑的是,虽然他熟悉的版本是1.4.2,但他似乎不太关心5.0到底有哪些进步,也没怎么花时间去了解这些进步.

在我的职业生涯中,类似的经历还有过好几次,有时候甚至据理力争,也无法说服领导. 于是我得到一个结论:当上领导的人都不太了解具体技术了,只是有人因循守旧,不愿意接受新变化,有人思想开放,可以接受新的方案. 可问题是,对具体技术不够了解的领导,他们的安全感来自哪里呢?他们不怕下属犯错误,甚至蒙骗吗?

这些疑问,直到几年后,我和徐易容一起吃了顿饭,听他讲 “一定要做自己真正想做的,觉得有意义的事情” 时,才真正解开. 我记得当时他举了个例子:

假设你是一个热衷技术的人,
领导安排你本年度的工作任务是,
把某项搜索的相关性提高五个点. 
于是你兢兢业业地安排年度计划,
前三个月读论文,
再三个月定方案,
然后三个月编码实现,
最后三个月测试并根据反馈并最终部署. 
真正上线之后,领导发现形势变化,
你的工作不再需要了,
然后给你安排下一年的工作. 

你付出了一年的劳动,
也挣了一年的薪水,
但是你的工作真的有价值吗?你会做得开心吗?

我听到这个例子的时候, 第一个想到的倒不是”要做真正向做的事情”, 而是”原来领导可以不要那么懂技术,这竟然是完全没有问题的”.

我想,这个领导或许并不懂关于相关性的那么多细节,也没有读过那么多论文,但是他可以动用资源去实现某个想法,这种工作才更有价值. 而且在这种情况下,下面的员工即便去欺骗领导,最终受损失的还是这名员工,因为他浪费了更多的成本,却没有真正的收获.

再后来,我在读书的时侯真正明白了”抽象”的意义,就是将某个具体的事物提炼到某个深入的层面,找到它和其它事物相通的地方. 这样,就能做到”触类旁通”. 比如你之前很懂蜡烛的生产,现在让你去负责手表的生产. 虽然两份工作不同,但如果你思考得足够深入足够抽象,就会知道,在合理配备资源,组织工序,优化流程,保证质量等方面,两者是有很多共性的,所以虽然不懂生产手表的细节,你也不算门外汉,更不妨碍你管理手表的生产. 回到之前那个”搜索相关性”的例子,我相信,合格的领导应该可以根据自己之前的经验和思考,把握这项任务的难度,工作量,意义,以分配资源和时间. 他对相关性的了解可能没有负责实现的程序员那么细致,但这一点也不妨碍他的工作,因为领导是在更高的层面上思考问题. 即便属下的程序员可以暂时欺骗他,时间稍长也会很容易被识破.

有些时侯,在更高的层面上思考问题也会遇到难以应付的具体难题,这时不妨大度应对. 假设有程序员建议将代码管理从SVN换成Git,有些领导会因为完全不了解Git而直接否定(当然要找各种理由), 因为这类似”让手工业时代管理蜡烛生产的领导去负责机械化的手表生产线”,跨度太大. 不过好的领导并不应该拒绝,因为身处这个行业,任何岗位的人都有义务经常更新自己的知识. 不懂Git,大可以去了解一番,然后才是履行日常领导的职责:判断这种切换会带来什么好处,团队中的大多数人是否能顺利切换,过渡的的代价是什么,可能面临什么风险… 衡量之后再做决定.

身为领导,在面对这种局面时还有一种特殊的便利,因为他可以很方便地借助所管理的程序员进行高效的学习,就像 @robbin 说的:

我的做法比较狠,把下属研发团队变成我自己学习新技术的延伸大脑,
鼓励他们不断学习和尝试,然后讲给我听,我再提出问题让他们给我解决. 
这样我就可以用最少的时间和精力,快速积累最多的知识. 

我自己在工作中也会定期组织学习分享会,讲解新鲜技术和工作心得. 对这种活动,领导出面主讲的效果不如由大家轮流主讲,领导只负责把关话题和质量就好了. 这样既有助于提高整个团队的水平和见识,又节省了大家的时间,更能促进团队成员的全面成长(要知道,许多程序员不是不善于表达,只是一直没有机会锻炼表达). 最关键的是,领导再不用担心某项技术自己懂得不够多了: “你是专家,来,请你来讲一讲,帮助大家共同学习吧. “

是也乎

  • 来自: 乱象,印迹
  • 生于湖南,游历大江南北,长春四年,北京五年,上海两年,现居广州.
  • 历任抓虾网主力程序员,盛大创新院高级研究员,广州某公司技术总监.
  • 以技术谋生,热衷用技术解决生活中的实际问题,创造真正的价值. 业余时间热爱阅读和思考,追求简单而有情趣的生活.
  • 写作了«正则指引»(电子工业出版社 2012年版),电子书«翻译漫谈»(图灵出版公司,2013年8月),独译«精通正则表达式(第三版)»(Friedl著,电子工业出版社2007年版),«技术领导之路–全面解决问题的途径»(Weinberg著,电子工业出版社2009年版),合译«权力与市场»(Rothbard著,新星出版社2007年版),审校«软件架构师应该知道的97件事»(电子工业出版社2010年版),«REST实战»(东南大学出版社2011年版).

自从,有了 管理学 好象,软件工程背景中的管理,就一直是种奇异的分支… 在其它领域, 领导从来没有要求一定要是专家, 有关部门领导各种事儿,自古就有的…

但是,为什么在电算领域,有了这种领导也必须有技术的不安定感觉? 可能:

  • 软件方面,从代码到产品的生产环节太少了,没有其它传统行业那么长的流程,
  • 所以,没有什么秘密可言
  • 所以,领导者只能说服为主
  • 所以,就必须有一定的技术背景,否则无法沟通

???

其实,只是双方的信任度不够吧, 因为软件领域,从代码到成品几乎没有什么成本, 而其中的脑力付出又无法衡量;

所以,无论程序猿还是项目经理,对于公司就变成,都不是无可替代的; 进而,所有人都不由自主的有不安全感; 最终,不安全感衍生出各种说服不能…

其实,核心的困难是让团队中其它人都能理解你的价值所在. 而专业化程度最进化最深的电算界,技术变化太快,不是一般人可以快速理解其它领域要点的, 所以,一般公司情况,都是将技术能力转换成普通财务都能理解的收益性 KPI 指标, 直接导致各种不服气…

所以? 改变自个儿的心态,人在作天在看,正如之前推荐的: G说公论:9 但行好事,莫问前程 一切认真的工作,归到底收获最大的应该是真正写代码的自个儿!

进一步的,也不应该不知道身陷悲惨工作而不自知, 推荐参考: 员工为何从一家公司离职

  • 你为什么从盛大离职 http://www.zhihu.com/question/22039985
  • 你为什么从豆瓣离职 http://www.zhihu.com/question/22038145
  • 你为什么从网易离职 http://www.zhihu.com/question/22030595
  • 你为什么从知乎离职 http://www.zhihu.com/question/22032444
  • 你为什么从新浪离职 http://www.zhihu.com/question/22031777
  • 你为什么从金山离职 http://www.zhihu.com/question/22032825
  • 你为什么从百度离职 http://www.zhihu.com/question/22029522
  • 你为什么从谷歌离职 http://www.zhihu.com/question/22039991

当期活动 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

珠海GDG[11.23]珠三角技术沙龙HOA.5

和久违的珠三角技术沙龙的小伙伴,共同来GDG 分享!

议程

  • 13:00 ~ 13:30 签到+暖场
  • ~ 14:30 刘老师 奇点与未来
  • ~ 15:15 Jeff(广州) 做个不务正业的技术宅
  • ~ 15:45 社交时间, 大合照
  • ~ 16:30 一斌(广州) 如何从法学生变为科技记者
  • ~ 16:45 Benn SensorTag 试玩汇报
  • ~ 17:00 大妈 再再再再谈Leo
  • ~ 17:15 北理 老高: 不甘社进展
  • ~ 17:30 Jason(广州) GLASS 生态

筹备活动 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PyCon2013CHina 珠海场

  • Python 年度大会
  • Pythonner 大趴
  • Pythonista 相亲集会
  • Pythonic 体验交流

请及时举报你身边的 华蠎行者!

巡阅


以上...


|_|0|_|
|_|_|0|
|0|0|0|

加入 珠海GDG

  1. 注册 G+
  2. 关注 GDG Zhuhai
  3. 成为 GDG Zhuhai开发者

通过 珠海GDG 可以:

    第一时间获知谷歌最新的技术,
    可以学到如何去谷歌平台上赚钱的思路和方法,
    可以认识很多有可能将来一起走上自己创业道路的人,
    可以学会把你的创新带向国际市场,
    参加那里的活动有经常和国际上的开发者们进行交流的机会...

PS:

若无意外,题图都是从原文提取或是通过 Google 图片搜索出来的, 版权属左, 不负责任 ;-)

PPS:

珠海GDG wechat/Blog 都是欢迎投稿的,只要追认内容吻合以下条件:

0. 有趣 ~ 至少是自个儿有兴趣的领域吧...
1. 有料 ~ 至少有点儿原创的东西吧..
2. 有种 ~ 至少不能是成功学吧!

有好物的,及时向大妈们吼: support@zhgdg.org

微信栏目

当前应该是:

    G术图书 (gb:推荐好书,书无中外)
    D码点评 (dd:麻辣评点,善意满盈)
    G说公论 (gt:时评杂文,新旧不拘)
    珠的自白(dm:大妈自述,每周一篇)
    海选文章(hd:得要相信,大妈法眼)

总之! 珠海的组委大妈们,决定开始坚持发文,方方面面细细同大家分享/交流

总之! 请大家告诉大家, 珠海生活中的技术社区 已经认真回归 微信,都来订阅吧!

订阅方法

  • 搜索微信号 GDG-ZhuHai
  • 或查找公众号: GDG珠海
  • 或扫描: qrcode_for_gh_5e32c47b5b23_258.jpg

GDG珠海 社区资源:

  • 邮件列表: gdg-zhuhai@googlegroups.com (可发空邮件到 gdg-zhuhai+subscribe@googlegroups.com 即完成订阅)
  • 微博: @GDG珠海
  • 微信: GDG珠海
  • G+ 主页: GDG ZhuHai
  • G+ 社群: ZhuHai GDG
2013-11-22  

声明: 本文采用 BY-NC-SA 授权。转载请注明转自: #ZHGDG#

comments powered by Disqus