“你要知道，如果你想做好一件事，你就必须自己动手。”Clive一边咕哝着，一边走回自己的房间。
Susan原本在埋头工作。她抬起头来，叹了口气。然后起身，跟着Clive穿过走廊，来到他的房间门口。她敲了敲门。
“什么事？我现在有点忙！”Clive一边应着，一边坐回他的电脑边上，然后对着Susan说，“给我解释一下框架的这个部分。”
“不行。”
他望着她，抬了抬眉毛，说：“不行？我可是你的老板。”
“没错！你是经理，但你在质问我的时候不像个经理。你像是闯进来捣乱的，而不是来帮忙的。我是技术主管。如果你对当前的状况有技术方面的问题，你应该跟我说。你应该跟团队说。你为什么不跟我说呢？你为什么不跟团队说呢？你为什么要乱动代码？”
“你看到Todd做的好事了吗？”
“看到了。”
“那你还能像没事一样站在那里？你没觉得不安吗？”
“我没觉得不安，因为我和团队今天早上已经把问题解决了。我们比你做得更多。这是谁的问题呢？”
“嗯，你和团队的问题。”
“谢谢！我们是怎么解决那个问题的呢？你问过我或团队了吗？”
“呃，没问。”
“好吧，其实你不知道，Todd和Ciddy正在一起解决这个问题。我们已经为线上的服务器打了一个补丁。Dick正与Samara合作开发性能测试，以期将来能避免发生同样的问题。所有这些你都不知道，是吧？噢，对了，我们还会复查代码和测试用例。你不知道吧？”
“呃，是的。”
“你想穿上超人的披肩，然后亲自去解决吗？”
“呃，是的。”
“嘿，Clive，你以前是程序员中的佼佼者，但那已经是5年前的事了。即使一年前你还是超人，到现在你也已经不知道我们把代码改成啥样了。你不可能跟上我们的开发节奏。因为我们有30个人一起写代码哪，他们在持续更新着框架，不断编写着自动化测试。你对我们的现状已经不再了解。你不再掌握第一手资料。你不再能从事重要的技术工作了，除非你真的想搞破坏。别高估自己了！”
“但是，当我看到问题的时候，我能帮忙做些什么呢？”
“来问我需要什么支持。来问团队。确保我们有充足的食物和水作为补给，”Susan笑开了，继续说，“基本上，你只需问就行了。我们会告诉你的。你给我们提供精神上的支持，但别去乱改代码！”
Susan站起身想要离开，最后说道，“噢，我已经撤销了你提交代码的权限。你只能看，不能改。我还修改了管理员密码。对于技术上的事，你不能再插手了。你是经理。当好你的经理吧！”
做好授权，别扎进问题里
作为管理者，当我们看到技术问题时，我们会经受想要介入帮忙的诱惑——要么直接出手解决问题，要么告诉别人怎么去解决。但是，那样做会破坏我们与团队建立起来的信任。一旦我们授权团队去解决问题，我们必须把问题留给他们。
如果你尽力把技术问题收回来，你其实并没有帮到团队。他们心想着你不会授权，最终不再去尝试解决问题了。反正你会在情况变糟的时候把问题揽回去，他们为什么还要去解决呢？
你还理解细节吗？
现在，扪心自问一下：你还理解团队所做的技术工作的所有细节吗？
我们一旦变成管理者，我们的技术问题解决能力就开始退化。最起码，如果我们在力争成为卓越的管理者，这些能力应该退化。为什么呢？因为我们花了更多的时间去与团队成员和其他管理者相处，而花在代码、测试、需求（或者以前伴随你成长的任何其他东西）上的时间越来越少了。
那并不意味着我们不要知道碰到问题要问谁，但我们不必知道所有那些技术细节。
我曾经做过开发总监。有一次，一位技术人员冲进我的办公室，抛给我一个非常技术性的问题，他以为我能解决。我听着听着，明白了问题之所在，也意识到谁能帮他。我不能直接到代码里去指出问题，但我知道问题藏在执行区域的某个地方——我们上周刚在那里改了点东西。我可以引导他去找合适的人，但我本人不能解决那个问题。
如果你不再理解细节，你还有职责要转进那些细节吗？不，那不是你该干的事！你可以推进问题的解决，但你本人不能解决问题。
知道你能做什么
作为管理者，我们最好去创造一个能让人们在其中施展才能、做好工作的环境。有时候，那意味着主持一次解决问题的会议。有时候，意味着确保他们有足够的服务器、调试器或白板。有时候，意味着排除外人（比如你的上司）的干扰。
那甚至可能意味着你要帮着读一读代码，或者，也许在一种极端的情况下，你需要编写或者测试一些代码。但是，一旦你成为管理者，提供技术层面的协助未必会起到帮助作用。
为什么呢？让我们来看一看管理者的职责吧。管理者之所以存在，就是要有目的地组织。他们把人员组织成项目团队，或者帮助他们自我组织。他们组织旨在解决问题或做好项目的团队。他们组织大家的想法。有时候，他们组织提供咖啡、百吉饼或甜甜圈。但是，一旦你成为管理者，并且过了几个星期之后，如果你还在组织代码或者测试，那么你管理和技术工作两样都做不好。你没有把你以前的工作授权出去，然后明白地告诉团队或者做出暗示，“我相信你们能够做好技术工作。”
但是，我的上司希望我两者兼顾
好吧，实实在在的问题来了。有一些二线经理认为，让一线经理管1～2个人的同时全身心投入技术工作是合理的。那些二线经理可能是对的，但那种一线经理也算不上是管理者。
存在那么一个转折点。一旦那位一线经理管理起第三个人，管理者的平衡必须从技术工作摆向管理。如果管理者不做那样的改变也一切正常，那么那位一线经理将经历一场危机之后才会认识到，他的管理职责必须优先履行。
向你的上司解释：你身上还肩负着管理职责，那要比技术工作更重要。你对你的团队有信心。你可以推动他们解决问题。你甚至可能在他们解决问题的过程中做出贡献。但是，你去动他们的代码、测试、需求或者干涉项目管理只会伤害团队。
你可能不适合做管理
如果你不能脱离技术工作，你可能意识到：管理不是你想要的。在那种情况下，与你的上司聊一聊吧，让他知道你想要什么。你有权做出改变！
但是，只要你还做着管理，那就抛开技术工作吧。你不再是技术团队的一分子。不要有那样的错觉，也不要再继续以往的行为方式。
原文来自：jrothman
译者介绍：陆其明，拥有10几年的软件技术研发和管理经验。已经出版的著作有《DirectShow开发指南》、《DirectShow实务精选》、《Windows Media编程导向》、《脚本驱动的应用软件开发方法与实践》，译作有《代码之道》、《高效能程序员的修炼》、《程序员的修炼——从优秀到卓越》。
联系客服
