程序员与技术管理者到底有何不同?

发现很多刚刚从程序员开发岗位晋升为管理岗位的人,对作为一名技术管理者,日常应该做哪些事情、怎么做、与一般程序员的日常会有哪些区别等方面还比较懵懂。

那么今天我想跟大家聊一聊,当我们开始从事技术管理岗位之后,我们应该怎么去重新定位自己,怎么在管理工作上做出自己的风格。

一、技术管理者一般有哪些类型?

要想做出自己的管理风格,对于新晋的技术管理者而言,首先肯定都很想要知道优秀的技术管理者们是怎么做的,然后看看有没有可以学习的地方,毕竟「模仿」是人类的天性。

那我们就来看看,一般技术管理者都是怎么去做事的,都有哪些类型?

简单点可以分为三类:

  • 授权型
  • 指导型
  • 冲锋型

三种做事类型,其实也就是三种技术领导力风格。

  1. 授权型

    擅长授权型的管理者,大多数是管理经验非常丰富的一类人。他们比较倾向于充分的授权/放权给下属团队,在安排好团队目标之后,就任由团队自主发挥,在任务过程中不过度干涉,只是会阶段性的去检查结果。

    这类的管理,对团队自身的要求会比较高,因为需要团队有较强的自治能力,团队中的每一个人都要有自驱动意识。非常适合比较成熟、精英的团队,在这种管理下,大家会有很大的自我发挥空间,做起事来非常顺利。但如果是刚起步的新团队就会觉得管理者太冷淡,缺少关注,甚至可能会导致团队出岔子。

  2. 指导型

    这类管理者,会和员工一起规划出工作方向和计划,指导员工应该关注的工作重点。会关心员工的发展,非常喜欢沟通和协调,善于做指挥,喜欢说「给我上」。这种类型发挥得好就能很好的驱动员工做事,发挥的不好,就会有点让人感觉受到命令和控制的味道。

    一般在「指导型」的技术领导力风格下面的团队,执行力都会比较强,也能较快的去实现团队目标。但是如果过于保姆化,就不容易培养起团队阶梯。

  3. 冲锋型

    这类管理者很喜欢亲力亲为,会在工作中和员工一起解决细节难题。最大的特点就是以身作则,用身教而不是言传,喜欢说「跟我上」。这类管理风格往往会让员工觉得很有归属感,非常受员工的欢迎,也容易得到大家的追随。但是因为这类管理者太过于注重亲力亲为了,所以一般不适合带领大型团队。

其实这三种类型严格来讲,并没有还坏之分,只有适合不适合的问题。每一种都有适合的团队和场景,最好的方式就是在团队不同规模、不同成熟度、项目不同阶段,采用不同的管理方式,就看你是否能驾驭多种领导力风格了。

二、技术管理者要做哪些事情?

找到了适合自己的管理风格之后,我们就可以开始激情澎湃的大干技术管理的事情了。那技术管理具体是要干哪些事情呢?在回答这个问题之前,我们还是先来看看技术管理者应具备的基本要求吧。

  1. 能够用正确的方式管理团队。发挥团队中每个人的特质,通过高效的协作方式,使团队朝同个方向使力。
  2. 能够提供解决问题的思路和方案。
  3. 能够做正确的技术评估和决定。
  4. 有扎实的基础技术和学习能力,并不断的提高对自己的要求。
  5. 能够找到正确的目标和方向。

我认为,上述几条就是作为一名合格的技术管理者应该具备的基本素质。

如果对上述这些管理素质进行一个提炼,其实我们也就明白了技术管理者应该做的事情主要也就是这些:

  • 带人
  • 做事
  • 定方向

这三条基本上可以囊括了管理工作的精髓。

可能你会觉得这是不是太笼统了,不够具体。那没关系,我们下面通过对比技术管理者与普通程序员的区别中,来慢慢渗透具体的工作内容。

三、技术管理者与普通程序员有哪些区别?

很多程序员即使在转技术管理之后,日常还是在做着程序员的事情,并没有从自我角色认知中转变过来。长此以往,就会产生职位与实际工作内容的不符。既没有达到上级的要求,也无法满足下级的期望。

那么这其中的工作认知,区别在哪里呢?我认为主要有以下几点:

  1. 团队干好 vs 自己干好

    当我们还是一线编码程序员的时候,对自己的要求就是把技术干好,完成上级交代的任务,对自己负责就可以了。

    但当我们转为技术管理的时候,我们就不单单要管好自己了,我们要带领着团队往前冲,要更多的关注团队成绩,要对团队整体负责,推动团队的成长。

  2. 主动规划 vs 被动执行

    当我们还是一线编码程序员的时候,我们的工作大多是听从安排的、被动的执行的。上级安排我做什么就做什么,更多的关注执行过程。

    而当我们转为技术管理之后,更多的工作需要自己去规划,需要去关注整体目标,将目标进行分解形成计划,而不是等上级安排活儿。如果你自己都没有规划,那你的团队就会更加没有方向了。

  3. 技术工具 vs 技术实现

    当我们还是一线编码程序员的时候,我们会全部关注在技术编码的实现上,这些就是我们的工作的大部分以及核心竞争力。

    而当我们转为技术管理之后,我们要把技术当做实现任务目标的一个工具,做一名技术的应用者,需要更擅长于技术评估而不是技术细节实现。

  4. 更大的协作范围 vs 团队内协作

    当我们还是一线编码程序员的时候,我们的协作对象一般是团队内、平级之间,真正的跨团队跨部门的协作比较少。

    而当我们转为技术管理之后,需要更多的与跨团队的协作、需要寻求上级、下级、跨不同职能部门的资源合作,对管理者的沟通协作能力有更高的要求。

  5. 合作关系 vs 竞争关系

    这一点稍微略有点现实。当我们还是一线编码程序员的时候,我们与团队成员的关系除了协作以外,可能会带有一些竞争的味道,同在一个团队内,谁的技术更好、谁的效率更好、谁的完成情况最优。

    而当我们转为技术管理之后,团队的所有成员都是来支撑我们的工作的,我们与团队内成员没有任何竞争的关系,全部都是协作共赢。有些刚从程序员岗位晋升管理的同学会遇到这样的情况,「团队中某某成员技术水平非常好,他会不会不服我呢,应该怎么跟他共事呢」,其实如果换个思维想一想就明白了,你跟他已经不再一个层面上工作了,没有任何的竞争关系,也无需从技术水平层面去比较,你需要的是与他协作好,让他辅助你,一起完成团队目标、一起实现共赢。

  6. 多维视角 vs 单一思维

    技术管理工作不能像敲代码一样非0即1了,管理工作中有很多中间态,不确定的因素,这些往往是对程序员之前单一习惯性思维的一个颠覆。转为技术管理之后,我们考虑问题,就需要从多个维度多个视角去思考。

  7. 合作思维 vs 分工思维

    当我们还是一线编码程序员的时候,处理问题往往习惯于依靠自身独立去解决。而做为技术管理者,往往遇到的问题可能会比较复杂,靠单人很难突破,就必须处处想到团队的力量,遇到问题,要汇聚团队的智慧、要寻找外部的资源多方的协助,要有合作的心态去处理工作。另外,当我们做编码的时候,经常讲究高内聚低耦合,所以习惯于模块之间职责分割清晰,甚至在与身边同事工作分工的时候也会带有强烈的边界意识。但是作为技术管理者,就更需要以全局的目标为己任,边界问题可能就不会那么明显了。

以上,就是对刚开始从事技术管理岗位的同学如何去重新定位自己、如何在管理工作上做出自己的风格的分学习与分享,希望能给大家一些启发。

本文原创发布于微信公众号「 不止思考 」,欢迎关注,交流Java、Web、架构、大数据、职业发展、技术管理。

 

发表评论