“你要知道,如果你想做好一件事,你就必须自己动手。”Clive一边咕哝着,一边走回自己的房间。

Susan原本在埋头工作。她抬起头来,叹了口气。然后起身,跟着Clive穿过走廊,来到他的房间门口。她敲了敲门。

“什么事?我现在有点忙!”Clive一边应着,一边坐回他的电脑边上,然后对着Susan说,“给我解释一下框架的这个部分。”

“不行。”

他望着她,抬了抬眉毛,说:“不行?我可是你的老板。”

“没错!你是经理,但你在质问我的时候不像个经理。你像是闯进来捣乱的,而不是来帮忙的。我是技术主管。如果你对当前的状况有技术方面的问题,你应该跟我说。你应该跟团队说。你为什么不跟我说呢?你为什么不跟团队说呢?你为什么要乱动代码?”

“你看到Todd做的好事了吗?”

“看到了。”

“那你还能像没事一样站在那里?你没觉得不安吗?”

“我没觉得不安,因为我和团队今天早上已经把问题解决了。我们比你做得更多。这是谁的问题呢?”

“嗯,你和团队的问题。”

“谢谢!我们是怎么解决那个问题的呢?你问过我或团队了吗?”

“呃,没问。”

“好吧,其实你不知道,Todd和Ciddy正在一起解决这个问题。我们已经为线上的服务器打了一个补丁。Dick正与Samara合作开发性能测试,以期将来能避免发生同样的问题。所有这些你都不知道,是吧?噢,对了,我们还会复查代码和测试用例。你不知道吧?”

“呃,是的。”

“你想穿上超人的披肩,然后亲自去解决吗?”

“呃,是的。”

“嘿,Clive,你以前是程序员中的佼佼者,但那已经是5年前的事了。即使一年前你还是超人,到现在你也已经不知道我们把代码改成啥样了。你不可能跟上我们的开发节奏。因为我们有30个人一起写代码哪,他们在持续更新着框架,不断编写着自动化测试。你对我们的现状已经不再了解。你不再掌握第一手资料。你不再能从事重要的技术工作了,除非你真的想搞破坏。别高估自己了!”

“但是,当我看到问题的时候,我能帮忙做些什么呢?”

“来问我需要什么支持。来问团队。确保我们有充足的食物和水作为补给,”Susan笑开了,继续说,“基本上,你只需问就行了。我们会告诉你的。你给我们提供精神上的支持,但别去乱改代码!”

Susan站起身想要离开,最后说道,“噢,我已经撤销了你提交代码的权限。你只能看,不能改。我还修改了管理员密码。对于技术上的事,你不能再插手了。你是经理。当好你的经理吧!”

做好授权,别扎进问题里

作为管理者,当我们看到技术问题时,我们会经受想要介入帮忙的诱惑——要么直接出手解决问题,要么告诉别人怎么去解决。但是,那样做会破坏我们与团队建立起来的信任。一旦我们授权团队去解决问题,我们必须把问题留给他们。

如果你尽力把技术问题收回来,你其实并没有帮到团队。他们心想着你不会授权,最终不再去尝试解决问题了。反正你会在情况变糟的时候把问题揽回去,他们为什么还要去解决呢?

你还理解细节吗?

现在,扪心自问一下:你还理解团队所做的技术工作的所有细节吗?

我们一旦变成管理者,我们的技术问题解决能力就开始退化。最起码,如果我们在力争成为卓越的管理者,这些能力应该退化。为什么呢?因为我们花了更多的时间去与团队成员和其他管理者相处,而花在代码、测试、需求(或者以前伴随你成长的任何其他东西)上的时间越来越少了。

那并不意味着我们不要知道碰到问题要问谁,但我们不必知道所有那些技术细节。

我曾经做过开发总监。有一次,一位技术人员冲进我的办公室,抛给我一个非常技术性的问题,他以为我能解决。我听着听着,明白了问题之所在,也意识到谁能帮他。我不能直接到代码里去指出问题,但我知道问题藏在执行区域的某个地方——我们上周刚在那里改了点东西。我可以引导他去找合适的人,但我本人不能解决那个问题。

如果你不再理解细节,你还有职责要转进那些细节吗?不,那不是你该干的事!你可以推进问题的解决,但你本人不能解决问题。

知道你能做什么

作为管理者,我们最好去创造一个能让人们在其中施展才能、做好工作的环境。有时候,那意味着主持一次解决问题的会议。有时候,意味着确保他们有足够的服务器、调试器或白板。有时候,意味着排除外人(比如你的上司)的干扰。

那甚至可能意味着你要帮着读一读代码,或者,也许在一种极端的情况下,你需要编写或者测试一些代码。但是,一旦你成为管理者,提供技术层面的协助未必会起到帮助作用。

为什么呢?让我们来看一看管理者的职责吧。管理者之所以存在,就是要有目的地组织。他们把人员组织成项目团队,或者帮助他们自我组织。他们组织旨在解决问题或做好项目的团队。他们组织大家的想法。有时候,他们组织提供咖啡、百吉饼或甜甜圈。但是,一旦你成为管理者,并且过了几个星期之后,如果你还在组织代码或者测试,那么你管理和技术工作两样都做不好。你没有把你以前的工作授权出去,然后明白地告诉团队或者做出暗示,“我相信你们能够做好技术工作。”

但是,我的上司希望我两者兼顾

好吧,实实在在的问题来了。有一些二线经理认为,让一线经理管1~2个人的同时全身心投入技术工作是合理的。那些二线经理可能是对的,但那种一线经理也算不上是管理者。

存在那么一个转折点。一旦那位一线经理管理起第三个人,管理者的平衡必须从技术工作摆向管理。如果管理者不做那样的改变也一切正常,那么那位一线经理将经历一场危机之后才会认识到,他的管理职责必须优先履行。

向你的上司解释:你身上还肩负着管理职责,那要比技术工作更重要。你对你的团队有信心。你可以推动他们解决问题。你甚至可能在他们解决问题的过程中做出贡献。但是,你去动他们的代码、测试、需求或者干涉项目管理只会伤害团队。

你可能不适合做管理

如果你不能脱离技术工作,你可能意识到:管理不是你想要的。在那种情况下,与你的上司聊一聊吧,让他知道你想要什么。你有权做出改变!

但是,只要你还做着管理,那就抛开技术工作吧。你不再是技术团队的一分子。不要有那样的错觉,也不要再继续以往的行为方式。

 
 

最新文章

  1. 几大排序算法的Java实现
  2. iOS 利用for循环创建九宫格
  3. Variant OLE automation
  4. CCF真题之节日
  5. 查看当前目录每个文件的大小(linux)
  6. C#自定义控件、用户控件、动态加载菜单按钮
  7. rest-framework总结
  8. (C/C++学习笔记)附页: C/C++各数据类型的相关说明
  9. [Spring] Spirng中的AOP进行事务的传播属性和事务隔离级别
  10. hadoop需要哪些技术支持
  11. BOF、EOF 属性
  12. Scrum Meeting 11.11
  13. Kafka 0.8 Producer处理逻辑
  14. TradingView 自定义指标
  15. Send a WhatsApp Message programatically -- Tasker WhatsTasker
  16. sass / scss
  17. e553. 作为浏览器访问URL
  18. Tornado异步(2)
  19. Vue结合原生js实现自定义组件自动生成
  20. 进入保护模式(一)——《x86汇编语言:从实模式到保护模式》读书笔记12

热门文章

  1. 关于 solusvm
  2. python学习笔记2_二元运算符和比较运算
  3. WPF DataGrid动态生成列的单元格背景色绑定
  4. JasperReport生命周期3
  5. Leetcode228. Summary Ranges汇总区间
  6. Leetcode173. Binary Search Tree Iterator二叉搜索树迭代器
  7. c++设计模式:代理模式
  8. sql 分页rownumber方式
  9. js中的定义变量之①用不用var
  10. java list转换json格式