程序员与技术管理者到底有何不同？
发现很多刚刚从程序员开发岗位晋升为管理岗位的人，对作为一名技术管理者，日常应该做哪些事情、怎么做、与一般程序员的日常会有哪些区别等方面还比较懵懂。
那么今天我想跟大家聊一聊，当我们开始从事技术管理岗位之后，我们应该怎么去重新定位自己，怎么在管理工作上做出自己的风格。
一、技术管理者一般有哪些类型？
要想做出自己的管理风格，对于新晋的技术管理者而言，首先肯定都很想要知道优秀的技术管理者们是怎么做的，然后看看有没有可以学习的地方，毕竟「模仿」是人类的天性。
那我们就来看看，一般技术管理者都是怎么去做事的，都有哪些类型？
简单点可以分为三类：
- 授权型
- 指导型
- 冲锋型
三种做事类型，其实也就是三种技术领导力风格。
- 授权型 擅长授权型的管理者，大多数是管理经验非常丰富的一类人。他们比较倾向于充分的授权/放权给下属团队，在安排好团队目标之后，就任由团队自主发挥，在任务过程中不过度干涉，只是会阶段性的去检查结果。 这类的管理，对团队自身的要求会比较高，因为需要团队有较强的自治能力，团队中的每一个人都要有自驱动意识。非常适合比较成熟、精英的团队，在这种管理下，大家会有很大的自我发挥空间，做起事来非常顺利。但如果是刚起步的新团队就会觉得管理者太冷淡，缺少关注，甚至可能会导致团队出岔子。
- 指导型 这类管理者，会和员工一起规划出工作方向和计划，指导员工应该关注的工作重点。会关心员工的发展，非常喜欢沟通和协调，善于做指挥，喜欢说「给我上」。这种类型发挥得好就能很好的驱动员工做事，发挥的不好，就会有点让人感觉受到命令和控制的味道。 一般在「指导型」的技术领导力风格下面的团队，执行力都会比较强，也能较快的去实现团队目标。但是如果过于保姆化，就不容易培养起团队阶梯。
- 冲锋型 这类管理者很喜欢亲力亲为，会在工作中和员工一起解决细节难题。最大的特点就是以身作则，用身教而不是言传，喜欢说「跟我上」。这类管理风格往往会让员工觉得很有归属感，非常受员工的欢迎，也容易得到大家的追随。但是因为这类管理者太过于注重亲力亲为了，所以一般不适合带领大型团队。
其实这三种类型严格来讲，并没有还坏之分，只有适合不适合的问题。每一种都有适合的团队和场景，最好的方式就是在团队不同规模、不同成熟度、项目不同阶段，采用不同的管理方式，就看你是否能驾驭多种领导力风格了。
二、技术管理者要做哪些事情？
找到了适合自己的管理风格之后，我们就可以开始激情澎湃的大干技术管理的事情了。那技术管理具体是要干哪些事情呢？在回答这个问题之前，我们还是先来看看技术管理者应具备的基本要求吧。
- 能够用正确的方式管理团队。发挥团队中每个人的特质，通过高效的协作方式，使团队朝同个方向使力。
- 能够提供解决问题的思路和方案。
- 能够做正确的技术评估和决定。
- 有扎实的基础技术和学习能力，并不断的提高对自己的要求。
- 能够找到正确的目标和方向。
我认为，上述几条就是作为一名合格的技术管理者应该具备的基本素质。
如果对上述这些管理素质进行一个提炼，其实我们也就明白了技术管理者应该做的事情主要也就是这些：
- 带人
- 做事
- 定方向
这三条基本上可以囊括了管理工作的精髓。
可能你会觉得这是不是太笼统了，不够具体。那没关系，我们下面通过对比技术管理者与普通程序员的区别中，来慢慢渗透具体的工作内容。
三、技术管理者与普通程序员有哪些区别？
很多程序员即使在转技术管理之后，日常还是在做着程序员的事情，并没有从自我角色认知中转变过来。长此以往，就会产生职位与实际工作内容的不符。既没有达到上级的要求，也无法满足下级的期望。
那么这其中的工作认知，区别在哪里呢？我认为主要有以下几点：
- 团队干好 vs 自己干好 当我们还是一线编码程序员的时候，对自己的要求就是把技术干好，完成上级交代的任务，对自己负责就可以了。 但当我们转为技术管理的时候，我们就不单单要管好自己了，我们要带领着团队往前冲，要更多的关注团队成绩，要对团队整体负责，推动团队的成长。
- 主动规划 vs 被动执行 当我们还是一线编码程序员的时候，我们的工作大多是听从安排的、被动的执行的。上级安排我做什么就做什么，更多的关注执行过程。 而当我们转为技术管理之后，更多的工作需要自己去规划，需要去关注整体目标，将目标进行分解形成计划，而不是等上级安排活儿。如果你自己都没有规划，那你的团队就会更加没有方向了。
- 技术工具 vs 技术实现 当我们还是一线编码程序员的时候，我们会全部关注在技术编码的实现上，这些就是我们的工作的大部分以及核心竞争力。 而当我们转为技术管理之后，我们要把技术当做实现任务目标的一个工具，做一名技术的应用者，需要更擅长于技术评估而不是技术细节实现。
- 更大的协作范围 vs 团队内协作 当我们还是一线编码程序员的时候，我们的协作对象一般是团队内、平级之间，真正的跨团队跨部门的协作比较少。 而当我们转为技术管理之后，需要更多的与跨团队的协作、需要寻求上级、下级、跨不同职能部门的资源合作，对管理者的沟通协作能力有更高的要求。
- 合作关系 vs 竞争关系 这一点稍微略有点现实。当我们还是一线编码程序员的时候，我们与团队成员的关系除了协作以外，可能会带有一些竞争的味道，同在一个团队内，谁的技术更好、谁的效率更好、谁的完成情况最优。 而当我们转为技术管理之后，团队的所有成员都是来支撑我们的工作的，我们与团队内成员没有任何竞争的关系，全部都是协作共赢。有些刚从程序员岗位晋升管理的同学会遇到这样的情况，「团队中某某成员技术水平非常好，他会不会不服我呢，应该怎么跟他共事呢」，其实如果换个思维想一想就明白了，你跟他已经不再一个层面上工作了，没有任何的竞争关系，也无需从技术水平层面去比较，你需要的是与他协作好，让他辅助你，一起完成团队目标、一起实现共赢。
- 多维视角 vs 单一思维 技术管理工作不能像敲代码一样非0即1了，管理工作中有很多中间态，不确定的因素，这些往往是对程序员之前单一习惯性思维的一个颠覆。转为技术管理之后，我们考虑问题，就需要从多个维度多个视角去思考。
- 合作思维 vs 分工思维 当我们还是一线编码程序员的时候，处理问题往往习惯于依靠自身独立去解决。而做为技术管理者，往往遇到的问题可能会比较复杂，靠单人很难突破，就必须处处想到团队的力量，遇到问题，要汇聚团队的智慧、要寻找外部的资源多方的协助，要有合作的心态去处理工作。另外，当我们做编码的时候，经常讲究高内聚低耦合，所以习惯于模块之间职责分割清晰，甚至在与身边同事工作分工的时候也会带有强烈的边界意识。但是作为技术管理者，就更需要以全局的目标为己任，边界问题可能就不会那么明显了。
以上，就是对刚开始从事技术管理岗位的同学如何去重新定位自己、如何在管理工作上做出自己的风格的分学习与分享，希望能给大家一些启发。