如果你是一名从技术层升上来的管理,当看到技术问题时,你会耐不住性子直接出手解决问题,或者告诉别人怎么去解决吗?快别这样做,这样只会把一切事情搞砸。为什么这么说呢?看完这篇文章你就知道了。
  
  “你要知道,如果你想做好一件事,你就必须自己动手。”Clive一边咕哝着,一边走回自己的房间。
   Susan原本在埋头工作。她抬起头来,叹了口气。然后起身,跟着Clive穿过走廊,来到他的房间门口。她敲了敲门。
   “什么事?我现在有点忙!”Clive一边应着,一边坐回他的电脑边上,然后对着Susan说,“给我解释一下框架的这个部分。”
  “不行。”
他望着她,抬了抬眉毛,说:“不行?我可是你的老板。”
“没错!你是经理,但你在质问我的时候不像个经理。你像是闯进来捣乱的,而不是来帮忙的。我是技术主管。如果你对当前的状况有技术方面的问题,你应该跟我说。你应该跟团队说。你为什么不跟我说呢?你为什么不跟团队说呢?你为什么要乱动代码?”
“你看到Todd做的好事了吗?”
  “看到了。”
  “那你还能像没事一样站在那里?你没觉得不安吗?”
  “我没觉得不安,因为我和团队今天早上已经把问题解决了。我们比你做得更多。这是谁的问题呢?”
  “嗯,你和团队的问题。”
“谢谢!我们是怎么解决那个问题的呢?你问过我或团队了吗?”
  “呃,没问。”
   “好吧,其实你不知道,Todd和Ciddy正在一起解决这个问题。我们已经为线上的服务器打了一个补丁。Dick正与Samara合作开发性能测试,以期将来能避免发生同样的问题。所有这些你都不知道,是吧?噢,对了,我们还会复查代码和测试用例。你不知道吧?”
   “呃,是的。”
  “你想穿上超人的披肩,然后亲自去解决吗?”
   “呃,是的。”
   “嘿,Clive,你以前是程序员中的佼佼者,但那已经是5年前的事了。即使一年前你还是超人,到现在你也已经不知道我们把代码改成啥样了。你不可能跟上我们的开发节奏。因为我们有30个人一起写代码哪,他们在持续更新着框架,不断编写着自动化测试。你对我们的现状已经不再了解。你不再掌握第一手资料。你不再能从事重要的技术工作了,除非你真的想搞破坏。别高估自己了!”
   “但是,当我看到问题的时候,我能帮忙做些什么呢?”
    “来问我需要什么支持。来问团队。确保我们有充足的食物和水作为补给,”Susan笑开了,继续说,“基本上,你只需问就行了。我们会告诉你的。你给我们提供精神上的支持,但别去乱改代码!”
   Susan站起身想要离开,最后说道,“噢,我已经撤销了你提交代码的权限。你只能看,不能改。我还修改了管理员密码。对于技术上的事,你不能再插手了。你是经理。当好你的经理吧!”
  做好授权,别扎进问题里

  
  作为管理者,当我们看到技术问题时,我们会经受想要介入帮忙的诱惑——要么直接出手解决问题,要么告诉别人怎么去解决。但是,那样做会破坏我们与团队建立起来的信任。一旦我们授权团队去解决问题,我们必须把问题留给他们。
  如果你尽力把技术问题收回来,你其实并没有帮到团队。他们心想着你不会授权,最终不再去尝试解决问题了。反正你会在情况变糟的时候把问题揽回去,他们为什么还要去解决呢?
  你还理解细节吗?

  现在,扪心自问一下:你还理解团队所做的技术工作的所有细节吗?
  我们一旦变成管理者,我们的技术问题解决能力就开始退化。最起码,如果我们在力争成为卓越的管理者,这些能力应该退化。为什么呢?因为我们花了更多的时间去与团队成员和其他管理者相处,而花在代码、测试、需求(或者以前伴随你成长的任何其他东西)上的时间越来越少了。
  那并不意味着我们不要知道碰到问题要问谁,但我们不必知道所有那些技术细节。
  我曾经做过开发总监。有一次,一位技术人员冲进我的办公室,抛给我一个非常技术性的问题,他以为我能解决。我听着听着,明白了问题之所在,也意识到谁能帮他。我不能直接到代码里去指出问题,但我知道问题藏在执行区域的某个地方——我们上周刚在那里改了点东西。我可以引导他去找合适的人,但我本人不能解决那个问题。
  如果你不再理解细节,你还有职责要转进那些细节吗?不,那不是你该干的事!你可以推进问题的解决,但你本人不能解决问题。
  知道你能做什么

  作为管理者,我们最好去创造一个能让人们在其中施展才能、做好工作的环境。有时候,那意味着主持一次解决问题的会议。有时候,意味着确保他们有足够的服务器、调试器或白板。有时候,意味着排除外人(比如你的上司)的干扰。
  那甚至可能意味着你要帮着读一读代码,或者,也许在一种极端的情况下,你需要编写或者测试一些代码。但是,一旦你成为管理者,提供技术层面的协助未必会起到帮助作用。
  为什么呢?让我们来看一看管理者的职责吧。管理者之所以存在,就是要有目的地组织。他们把人员组织成项目团队,或者帮助他们自我组织。他们组织旨在解决问题或做好项目的团队。他们组织大家的想法。有时候,他们组织提供咖啡、百吉饼或甜甜圈。但是,一旦你成为管理者,并且过了几个星期之后,如果你还在组织代码或者测试,那么你管理和技术工作两样都做不好。你没有把你以前的工作授权出去,然后明白地告诉团队或者做出暗示,“我相信你们能够做好技术工作。”
  但是,我的上司希望我两者兼顾

  好吧,实实在在的问题来了。有一些二线经理认为,让一线经理管1~2个人的同时全身心投入技术工作是合理的。那些二线经理可能是对的,但那种一线经理也算不上是管理者。
  存在那么一个转折点。一旦那位一线经理管理起第三个人,管理者的平衡必须从技术工作摆向管理。如果管理者不做那样的改变也一切正常,那么那位一线经理将经历一场危机之后才会认识到,他的管理职责必须优先履行。
  向你的上司解释:你身上还肩负着管理职责,那要比技术工作更重要。你对你的团队有信心。你可以推动他们解决问题。你甚至可能在他们解决问题的过程中做出贡献。但是,你去动他们的代码、测试、需求或者干涉项目管理只会伤害团队。
  你可能不适合做管理

  如果你不能脱离技术工作,你可能意识到:管理不是你想要的。在那种情况下,与你的上司聊一聊吧,让他知道你想要什么。你有权做出改变!
  但是,只要你还做着管理,那就抛开技术工作吧。你不再是技术团队的一分子。不要有那样的错觉,也不要再继续以往的行为方式。
    来源:jrothman