日志
[转贴]工程师到管理者的转变
||
工程师到管理者的转变
http://bbs.ednchina.com/BLOG_ARTICLE_3011373.HTM
魏文侯与田子方饮酒赏乐时听出音律有误，对乐师说:“编钟的声音不对称吧,左边声音高.”田子方笑了.魏文侯问:“您为什么笑，我说错了吗？”田子方说:“做为国君，最重要的是知道怎么任用乐官，而不是关心乐律的准确。现在您精通乐律，我担心阁下疏忽用人了.”魏文侯听后言善.
这里说明的一个道理,就是作为管理者不要过于沉溺于具体的执行事务.当讨论一个设计时,参与讨论的管理者尤其是内行有过实际经验熟悉技术的管理者,总是忍不住要具体指出应该怎么做如何做.其实这在无意中犯了几个错误.一是容易给下属造成挫折感,尤其是在工程师也知道应该怎么做,有自己可行的思路和计划时.二是抑制了工程师的积极性养成了依赖,遇到挑战性的工作也等管理者拿主意.慢慢的到具体的细节执行都听管理者安排后再做.最后使得管理者陷于具体事务,执行者也失去了自主性和主动性.尤其在全球化的公司,地域和人文的关系,使得效率明显降低,并不利于人才的成长.
本人有过类似的经验,一个项目开始也任命了PM.开始大事小事我们都要email和电话讨论.但每次讨论时我都重复一下项目的原则和做决定要考虑的方式,比如这个产品是从无到有,开始的元器件成本不重要,多做几次PCB也不重要,重要的是先拿出来样品,以便展示宣传和参加会展.建议PM按照符合原则和对最后目标最有利的方式作出自 己决定.慢慢的直接发给我的email越来越少,更多是PM自己跟各方的联系协调,只有当出现影响最终交货的情形时才讨论一下.这样各方面积极性都发挥了,自己也减少了压力,有精力考虑些其它事情.
从工程师出身的管理者要忍住对自己了解的技术和设计发表意见的欲望,或者不自觉在大小事都发表具体做法的惯性.对于知道工程师有能力和经验做到的事情,可以参与review但不要指示怎么做,让他自己拿主意和负责任.对于出现的问题一时没有答案但知道下属有能力做好的,也尽量别先发表意见.一个研发的主管本人认为最主要的有这么几点: 1)明白产品研发的风险所在,策划解决问题的资源及人力安排. 2)制定合理的流程但不要去管理过程,只是在过程中出现red flag时介入. 3)目标管理,让参与项目的个体自己负责任和做相应的决定.
老子曰 "以不智为智". 孟子也说"人有不为也,而后可以有为", 俗话说抓大放小, 西方公司也有避免micro management的说法, 其实都是一个意思.
