layout: post author: zoomq title: 珠的自白:11 领导需要比下属更懂技术吗 description: ~ 大妈自述,每周一篇 categories: GdgDAMA tags: gdg 珠的自白 dm wechat people
领导需要比下属更懂技术吗?
领导必须更懂技术吗?这是个问题. 做了领导以后,因为工作的关系,许多人都不那么熟悉基础的技术了,结果自己心里没底,更怕遇到问题时在下属面前丢脸. 所以,有些人选择了双管齐下--既不放弃领导的工作,又不放弃原有的技能,结果疲惫不堪. 还有人干脆选择不当领导了,因为有手艺,才有安全感.
这个问题也困扰过我,而且始终找不到"合理"的答案,最终还要靠亲身的工作经验来解答. 所以在正式回答这个问题之前,让我先讲讲自己的亲身经历.
在我刚工作的时候,业界使用的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年版),<
>(东南大学出版社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 体验交流
请及时举报你身边的 华蠎行者!
- 举报热线: zoomquiet+pycon (AT) gmail.com
- 官网: http://cn.pycon.org/2013
- [12.8]PyCon2013China 珠海场报名表
以上...
码不停提马上无虫 ;-)
|_|0|_| |_|_|0| |0|0|0|
加入 珠海GDG
- 注册 G+
- 关注 GDG Zhuhai
- 成为 GDG Zhuha开发者
通过 珠海GDG 可以:
第一时间获知谷歌最新的技术, 可以学到如何去谷歌平台上赚钱的思路和方法, 可以认识很多有可能将来一起走上自己创业道路的人, 可以学会把你的创新带向国际市场, 参加那里的活动有经常和国际上的开发者们进行交流的机会...
PS:
若无意外,题图都是从原文提取或是通过 Google 图片搜索出来的, 版权属左, 不负责任 ;-)
PPS:
珠海GDG wechat/Blog 都是欢迎投稿的,只要追认内容吻合以下条件:
0. 有趣 ~ 至少是自个儿有兴趣的领域吧... 1. 有料 ~ 至少有点儿原创的东西吧.. 2. 有种 ~ 至少不能是成功学吧!
有好物的,及时向大妈们吼: [email protected]
微信栏目
当前应该是:
G术图书 (gb:推荐好书,书无中外) D码点评 (dd:麻辣评点,善意满盈) G说公论 (gt:时评杂文,新旧不拘) 珠的自白(dm:大妈自述,每周一篇) 海选文章(hd:得要相信,大妈法眼)
总之! 珠海的组委大妈们,决定开始坚持发文,方方面面细细同大家分享/交流
总之! 请大家告诉大家, 珠海生活中的技术社区
已经认真回归 微信,都来订阅吧!
订阅方法
- 搜索微信号
GDG-ZhuHai
- 或查找公众号:
GDG珠海
- 或扫描:
GDG珠海 社区资源:
- 邮件列表: [email protected] (可发空邮件到 [email protected] 即完成订阅)
- 微博: @GDG珠海
- 微信: GDG珠海
- G+ 主页: GDG ZhuHai
- G+ 社群: ZhuHai GDG
Author: /mail / gittip / github