转型技术管理后，应该避踩哪些坑？

washington02

. J3 l4 v/ W0 l+ f2 K
「我搞得定」不一定是好事

• 做技术的人，大多很享受「搞得定」的快感。毕竟，技术既是我们安身立命的本钱，也是我们的价值来源——能用技术去搞定各种事情，既让我们开心，也给我们经济回报。看看我们身边，如果有这样一个人，无论出了什么难题，他都可以搞得定，那么他就是牛人，当然应当受到大家的敬仰，成为学习的楷模。我们很多人，内心里都希望成为这样的人。
  
• 但是，如果你希望从技术转向管理，强调「我搞得定」却不一定是好事。因为「管理」从某种意义上来说，就不再是自己单干，而是要驱动一群人，借助团队创造更大的优势和能量。如果团队每次遇到问题，技术管理者热衷于高喊「我搞得定」，冲锋在第一线，单从事情来说或许很好，但从团队来说未必很好。
  $ E- }( O& D4 a
• 我们要认识清楚，高喊「我搞得定」的时候，他的身份是个人贡献者，而不是团队的管理者。长此以往，技术管理者很可能越发相信「只有我才搞得定（才能放心）」，失去了对团队成员的信任，忽略了团队能力的培养；另一方面，团队也越来越依赖管理者出头解决疑难问题，缺乏主动挑头的勇气。如此往复下去，进入恶性循环。管理者精力透支，团队却在原地踏步。
  
• 要解决这个问题，技术管理者一定要克制「我搞得定」的冲动。比较好的办法是，把「我搞得定」当成不轻易亮相的法宝。即便你知道自己能搞得定，也应当忍一忍，等待团队里有人出头来搞定。如果有人确实搞定了，要多加肯定。如果不得已必须自己出手，完事之后应当仔细想想，这个问题有没有必要自己出手，是不是应该培养人来搞定这些事，如何培养这样的人。
  9 y$ \7 A: f- n8 O/ Q% T: H2 ~2 X' w
  
  

+ m1 N8 A: q% ]" K5 d  Y- D

「我搞不定」不一定是坏事

• 如果说「我搞得定」对技术人员来说是信心的来源，那么「我搞不定」就是丢脸的象征。我知道很多技术人员都羞于承认「我搞不定」，宁愿翻阅书籍、上网搜索，也不愿意问问同事，更不用说承认「我搞不定」了。因为，这就等于说「我水平不行」嘛。
  . M$ J: ^+ Z* V" |% O, v/ E8 L/ @3 W
• 很多技术人员转型管理之后，仍然带有这种思维惯性。不论管理什么团队，做什么业务，都希望百分百杜绝「我搞不定」，避免“「我水平不行」的尴尬。
  . d! E& h7 {! `/ @' H
• 可惜他们没有意识到，角色不同，定义也不同，此「水平」非彼「水平」。对专业技术人员来说，「水平」基本等同于「专业技术能力」，而对于管理者来说，「水平」基本等同于「动用资源解决问题的能力」。也就是说，不怕你自己个人搞不定，就怕你找不到资源搞定。
  
• 可以想象，承认「我搞不定」的管理者，一定会更迫切地为团队补充高水平的人才，壮大团队的力量。对团队成员来说，如果自己动手搞定了管理者自己承认「搞不定」（谁知道真假呢）的问题，也更容易获得成就感，积累继续成长的动力。
  
  
  1 [- r9 Y, {* x

两点之间，直线未必最短

• 技术的世界是单纯、简单、直来直去的。许多语言、框架、工具，更是在努力塑造「凡事有且只有一种最优解法」的思维。所以，在技术人员看来，很多问题本身没有那么复杂，两点之间，直线就是最短，这是毫无疑问的。
  
• 但是身为管理者，要应对的局面、考虑的问题都要复杂很多，直截了当地解决问题，很多时候并不是最可取的方式。因为，管理者不是一个人在战斗，往往需要借助其他人的力量去达成目标，并且在这之后，还需要持续与其他人保持良好的合作关系。这时候，你认为的「最短路径」和「最优解」，未必是其他人认同的「最短路径」和「最优解」。
  
• 假设有个任务，你觉得用 Python 写一点代码就能完成，这是最好的办法，天经地义的，其他人却认为用 Java 或者 Ruby 才更好。这时候，你可以动用权威，直接命令他用 Python 来写，甚至他不会也可以命令他从头学起，但你也要考虑：如果不能让对方心服口服，很可能即便本次按照你的意愿完成了任务，心里却埋下了别扭甚至埋怨的种子，日后不知何时会出土，在想不到的地方给团队添乱。
  4 z: G+ m( |3 x7 I) ~* j% w$ f
• 如果能多点耐心，让他按照自己的意愿去解决，同时给他看看你认为更好的办法，比较讨论之后得到一致，也许花的时间长一点，日后的收效却大不相同。而这种耐心的培养和启发，正是很多优秀管理者的做事方式，因为他们知道，两点之间并不是只有直线可以连接，下跳棋同样可以达到目标，而且难度一点也不低。
  1 m7 C3 i3 T( p  p  M
  
  5 Z3 Q  e6 i1 T& `5 i

理论是灰色的，而生活之树常青

• 很多人都知道歌德《浮士德》中的名句「理论是灰色的，而生活之树常青」。但是，真正能参透其中道理，并且运用到自己工作中来的技术人员，却是少之又少。
  
• 我见过很多技术团队相当喜欢干的一件事，就是抱怨业务团队的愚蠢：连这么简单的都不会，还怎么混？怎么根本没有逻辑？这也不懂那也不懂，整天不知道在干嘛…… 越抱怨，越有共同语言，越觉得自己人有共识，怎么做人、怎么做事，这些问题本没有那么复杂，本来有公认的答案。
  
• 在我看来，技术人员之所以有这样的认知，很多时候是过于相信技术的力量了，忘记了「理论是灰色的」。技术当然很强大，很有力量，但也有很多问题是技术解决不了的——从去年的月饼事件，到前不久的搜题风波，说起来都是技术问题，但哪一件是单凭技术就能解决，甚至能像技术问题那样容易达成共识的呢？
  * G- b1 q# e' g4 @" n, P7 R' e
• 如果承认「生活之树常青」，就会发现不一样的世界。尤其是身为技术团队的管理者，多半需要和不同职能的团队打交道，在这种时候，技术不再像以前那样是唯一的标准和讨论的基础。
  $ D8 [, v4 p9 J/ d
• 你知道产品团队的目标是什么吗？你知道运营团队整天在考虑什么吗？你知道客服最近忙于解决什么问题吗？你知道商务遇到了什么困难吗？如果你愿意放下「技术主导一切」的观念，把自己当作不懂技术的人，设身处地理解其他人的处境和工作，技术的价值往往才能得到更大程度的实现。
  ( L+ u2 J' ]7 P' Z( a9 |: t  z6 ]
• 前几周谷歌出现了沸沸扬扬的「性别歧视事件」。我总觉得，大家太容易形成刻板印象，比如男人适合干什么，女人适合干什么，并脑补出一些所谓的理由。全然不顾无数科学研究早已经证明，女性在科学方面表现不如男性，更多不是生理原因，而是社会观念和习俗作用的后果。
  - }9 m0 t! i; X  h; Y
• 对于技术人员转管理，很多人更喜欢从性格上找原因，于是管理岗就变成了一个「天注定」的选择。但是在我看来，转管理并没有那么玄乎，即便「管理能力」，培养起来也是有章可循的。
  
  / c- {! o/ m, g6 B' E" y

embnn

理论是灰色的，而生活之树常青