点击上方蓝字关注灸哥聊管理

今天我们俩聊程序员走向技术管理之路的第五个阶段，那就是如何做好一名称职的技术经理。

如何做好称职的技术经理？

从管理一两个下属的技术 TL 到管理一个团队的技术经理，看起来只有人数变多的一小步，但实际上团队管理还涉及到人事管理之外的方方面面。作为团队的管理者，你的工作属性已经发生变化了。

从你接手一整个团队开始，每当你的职业生涯更进一步时，都会面临全新的工作需求和挑战。随着职业生涯的发展，你所面临的最大困难就是需要用全新的方式去工作。

管理工作并不是技术专家工作的自然延展，而是需要你学习全新的技能来面对全新的挑战。

作为一个管理技术团队的技术经理，他要做到：

1. 研发经理需要在不影响团队整体工作进度的前提下，承担一定程度的技术编码工作。除此之外，还需要可以识别团队中的瓶颈和阻碍，并能帮助团队提前消除这些阻碍

2. 研发经理需要为公司的整体成功作出贡献，需要具备识别高价值需求和项目的能力，并且能够确保团队可以交付这些高价值的需求和项目

3. 研发经理需要和产品经理深度合作，共同定义和优化产品需求，确保需求和项目的按时保证质量的交付

4. 研发经理需要统筹规划自己团队的人力资源，积极进行招聘工作，满足团队的发展需求

5. 研发经理需要有独立管理的能力，要具备管理团队中与自己技术领域不同的成员的能力

此阶段的管理者请务必把注意力集中在技术、战略和领导力层面。

保持对技术的关注

随着职业生涯的发展，你可能写代码的时间越来越少，但你却需要承担起引导技术决策的工作。因此，作为技术经理，保持对技术的关注是至关重要的。尽管你可能会逐渐脱离具体的编码工作，但是你仍然需要保持对技术领域的敏感和了解，因为技术管理是一项技术工作，而不仅仅是简单的人事管理。

首先，作为技术经理，你需要承担引导技术决策的责任。

尽管团队中可能有架构师和其他资深技术成员负责设计系统和关注实现细节，但作为技术经理，你的职责是监督他们的工作并确保技术决策符合基本的技术要求，并与团队的需求和业务目标相一致。你多年来在技术领域积累的经验和直觉会在这方面发挥重要作用。

其次，维持对技术的了解有助于赢得团队的尊重。

如果你的技术能力不够强，你将面临更多的困难，而且你未来的职业发展选项也会受到限制。因此，在你努力向技术管理方向发展的同时，绝不能忽视自身技术能力的培养。然而，在转型过程中，你需要做出取舍。管理者的职责，如参加会议、规划项目进度等，可能会占据大量时间，使你很难保持写代码的时间。但是，如果你过早地脱离具体的编码工作，可能会导致技术能力的退化。因此，即使在管理岗位上，你也应该承担一些小型技术工作，这有助于你识别团队面临的挑战和流程问题。

作为团队的领导，你还需要负责技术的可行性评估。具备良好的技术工作量评估能力可以更好地与产品经理合作，并制定出最佳的实现方案。通过了解系统内部代码，你能够更容易地找出问题，并制定相应的解决方案。

尽管许多公司可能不提供给管理者编码时间，但你仍应该尽可能参与技术工作，直到你确信自己已经具备了足够的编码和系统设计能力。如果你过早地脱离技术工作，可能会成为你职业发展中的一个重要障碍。

找出技术团队不和谐的问题

很多管理者都会面临接受一个明显不那么和谐的团队，比如团队的任务计划经常错过截止时间，导致团队成员工作不开心，甚至一个接一个地辞职。产品经理对团队的表现感到十分不满，而团队对产品经理也十分不满。团队对目前的工作目标缺乏激情和动力。有些团队成员可能因为负能量、人际关系问题、超负荷工作而感到不满，这可能影响到整个团队的氛围和效率。

此时，作为刚接手这个团队的技术经理，能看到这个团队的不正常，但是又不能确定具体是哪方面的问题。那从我个人的管理经历，我会给大家总结介绍技术团队常见的一些不和谐的问题，这样可以一起探讨如何去识别并且解决这些问题。

部分技术管理者会认为有些场景就是无法交付的，比如，你带领团队正在深入研究某一个新技术，可能就没什么可交付的内容。但是，作为管理者，要知道即使是做技术研究工作的团队，也需要有相应的研究目标，并制定实际交付物计划。

作为团队的管理者，你可能会担心团队的压力过大，所以如果团队偶尔错失一个交付日期，你也就睁一只眼闭一只眼了。但是，这里最关键的是，平衡什么时候该对团队施加压力与什么时候该释放团队的压力。如果你目前还能参与团队编码工作的话，那么卷起袖子实际干活，帮助团队一起完成预期目标，或者主动找出团队目前进展不佳的部分，直接与其对应的工程师结对编程，了解具体情况是最有效果的。

很多时候技术团队进展不佳的原因是所使用的工具与其所涉及的流程陈旧过时，阻碍了工作的进行。一个很常见的案例就是团队每星期只尝试进行一次代码发布，甚至不能做到每周发布。这种低频的发布过程通常会掩盖团队的一些技术问题，比如发布工具的不足，存在大量的人工测试环节，或者每次发布的产品功能过于复杂，以及团队不能很好地进行工作拆分，等等。现在你接手了这个团队，你需要做的就是推进团队解决这些瓶颈问题。

很多时候我们会过分容忍那些“聪明的混蛋”，就是那种工作能力很强，自己工作产出也很高，但是缺乏团队精神，让周围的每个人都很不开心的人。与之相伴，程度较轻的一种情况是，团队中存在那些滋生事端、心怀不满、沉迷于风言风语并且拉帮结伙的人。这些我都会称之为职场负能量。

这就需要管理者勇敢地站出来，将人际关系问题扼杀在萌芽期。在处理这种情况时，尤其是你第一次处理该类问题的时候，可以寻求上级领导和 HR 团队的帮助。但是，也要小心，可能你的上级领导处理起这种问题来比你还困难。因为作为间接领导，他往往只能看到成员的工作产出，不一定能够了解团队成员的具体情况。所以，你一定要做好与该员工以及自己的上级领导进行一系列谈话的准备。也许最后的处理方式会是，将该员工转到另外一个组里或者辞退。

团队中负能量过强的人相对要好处理一些。首先你要向他明确说明，他目前的这种做法是不恰当的，要给出一些明确具体的案例。其次应该在某种事件发生后及时地提供反馈，纠正他的言行。有的时候，负能量来自该员工对工作不满意。最好的处理结果就是其平稳离职。所以，你必须提前做好准备。而有的时候，该员工其实并没有意识到自己的行为对团队的其他成员造成了何种影响，和他进行一次简短的谈话就足以解决这个问题了。

请切记不要将那些大声表示对自己不满的人留在团队里太久。不管你的管理经验有多丰富，都会被这样的人拖累。有时候最好的防御方式就是主动出击，快刀斩乱麻。

这个问题解决起来要相对容易一些。一般来说员工因超负荷工作所产生的不满情绪，都源自一种你可以直接解决的根源问题。比如如果超负荷工作来自生产系统的不稳定，那么你作为技术管理者的职责就是要求产品计划减缓一段时间，以便增强产品的稳定性。我的建议是，在每次工作计划会议上至少留出 20% 的时间给团队进行可持续性工作的开展，用来偿还技术债务以及技术优化的工作。

如果目前的超负荷工作是源自一次压力重大、十分关键的产品发布，那么应对起来要注意以下两点。首先你应该承担为团队喝彩的角色，尽可能在一切方面为团队提供支持，若能亲自为团队分担一定的技术工作就更好了。哪怕是给团队订个加班晚餐也行。告诉团队你对他们的辛苦工作很感激。同时向他们明确说明，在本次产品发布会之后，会有一次明确的休假补偿。

在加班的过程中，尽量增加一些工作的趣味性和关怀措施。有的时候，一次紧张的工作反而是团队增进感情的好机会。团队会记住你是和他们患难与共，还是躲在一边做自己的事情。其次作为管理者，你应该尽可能地从这次加班中吸取教训，并且尽量避免再次发生类似情况。如果可能的话，砍掉一些功能，尽量推迟那些真的不合理的日期。压力有的时候是难免的，但是不能无缘无故地、经常性地、持续性地加班。

你接手的团队可能与产品团队的合作不顺利，或者与设计团队不协调，抑或与另外一个技术团队不搭钩，而且这种合作问题影响了所有人的工作效率。这里没有什么快速解决方案，但是你仅仅表示出愿意改善合作问题的态度，就能起到很大作用。

如果你还没有这样做的话，赶紧和对应的工作伙伴展开定期的会议，以讨论解决合作上的问题。你可从团队中及时收集反馈信息，并且开展有建设性的改进谈话。要注意的是，为了避免状况变得更糟，不管你是否同意团队成员的意见，都应该在公开场合支持他们的立场。

如果团队内部有合作不顺畅的情况，那么你应该尝试给团队成员寻找并创造一些工作之外的相处机会。比如说，和团队成员一起外出吃午餐，周五下午和大家一起离开公司去参加一些有趣的活动，在组内聊天时鼓励大家多一些幽默，以及和团队成员多唠一些家常，等等，都是有效培养团队凝聚力的好办法。

作为一个新任管理者，我能理解你可能对这种类型的情感培养方式有点发怵，但是哪怕是最内向的人，也渴望和自己的团队成员产生认同感。假设团队中不存在上述的人际关系危机，那么在这方面只要做一点点改进，就能对增进团队的友好氛围起到很大作用。

团队的保护伞

很多管理大师和管理课程都告诉管理者们，如果想让你的团队执行高效，务必成为团队的保护伞，要为团队抵挡破事儿、烂事儿。让团队成员专注在自己需要交付的工作上，不要被团队以外的人事波动、政治斗争或者公司经营不善等因素的影响。

我虽然在之前的创业公司一直这么做，但是也是客观原因和场景决定我不得不这么做，不然团队的主动离职率会很高，管理成本不可预测。不过从我个人的管理风格来讲，我对这种说法是持有保留意见的，我认可团队如果过多地暴露在与自己无关的风波之下，很容易分散注意力，添加无谓的压力。对技术团队来说，他们确实不需要知道公司的管理问题、经营问题以及其他的人际关系风波。我最自豪的事情就是，周围的人不断入职离职的时候，我的团队安心做事，几乎毫无波动。

作为管理者帮助团队遮挡一些无意义的事情是很重要的。换句话说，你的工作应该是帮助团队成员了解哪些目标是关键的，并且帮助他们专注在这些关键目标上。然而，指望你能替整个团队遮风挡雨是不现实的。有时有必要让某些外部压力直接传递给团队成员。这里不是为了给他们增加压力，而是为了让他们了解自己目前工作的背景信息。

在一点上过去的我做的是不好的，一味地保护太多。类似我这种保护伞类型的管理者，更要明确地给自己的团队制定清晰明确的目标，是帮助团队成员提高专注力以及激励团队成员的最佳方式。但是，作为人性的一部分，团队成员要认同某个目标，就必须对该目标所携带的背景信息有一定了解，从而能理解自己工作的目的是什么。例如，如果某个系统不能在11月上线运行，将会导致公司运营困难，那么你的团队就应该了解不能及时发布系统的后果是什么。合理的背景信息能够帮助团队更好地做出决策，更好地分配自己的力量。作为管理者，你应该推进团队共同决策，而不是一个人说了算。

保护伞类型的管理者的另一个常见错误是他们以为，可以拒绝外界风波的存在。如果公司的另一个部门进行了裁员，而你没有公开说明这一点，但你的团队成员私下里获得了该消息，那么，你不仅没有保护自己的团队，反而创造了一种好像什么糟糕的事情即将发生，但是你却故意不说的感觉。如果你直截了当地公开说出你所知道的信息，不掺杂个人情绪，反而会制止谣言的流行，消除对自己团队的不良影响。

你当然可以充当保护伞的角色，但是你不是团队成员的父母。有的时候，伴随着对团队成员的保护和辅导，管理者容易与团队成员形成一种类似于父母与孩子之间的那种关系。管理者会认为团队成员是需要事事保护、精心照料，以及小心对待的小孩。但是，这是错误的。你的团队成员是由成年人组成的，他们理应像成年人一样被尊重。这种互相尊重，对你自己和对团队成员来说都十分重要。如果你将团队成员当作自己的孩子，很容易将他们的错误视为自己的个人失败，又可能会因为他们与你意见不一致而掺杂了个人情绪，影响决策。

这是我这两年的管理过程中做的尤其不好的地方，我要进行深刻反思。

推动团队做出好的决策

作为技术管理者，在团队决策过程中，你扮演了什么样的角色呢？

如果你的团队中有产品经理的存在，那么通常来说他会负责制定产品路线图，以及跟踪你团队所负责实现的产品功能情况。同时，技术团队中要有技术组长这一角色，其在深入技术工作的同时正在进行一定程度的项目管理和技术规划工作。那作为技术经理的你，应该做些什么呢？

你需要承担的责任将远远超过自己的想象。虽然产品路线由产品经理负责规划，技术细节由技术小组长负责，但技术经理则需要对整个团队的进度负责。你身为团队管理者，事事独断专行是不可能的。通常情况下你只能试图引导团队做出决策，但你需要对所有这些决策的结果负责。

团队中的产品负责人或者业务负责人，早已经习惯利用业务数据、客户行为数据以及市场预测来辅助自己的决策。那我们就可以增加新的数据源来辅助团队做出决策。比如收集团队的工作效率数据（如每个产品功能的完成时间）及工作质量的数据（如花费在线上故障处理的数据，或者在 QA 阶段或上线之后才发现的 bug 数量）。这些高度技术性的工作效率数据对技术和产品的决策过程都有帮助。

强有力的管理者最关心的是，自己的团队不断地打胜仗，以及培养团队不断地打胜仗的能力。这意味着，管理者的首要任务是，搞清楚对自己团队的客户来说，什么才是最重要的。无论团队的当前任务是为客户编码、开发内部工具，还是负责团队支持工作，总有一些团队会依赖于你的工作结果，而他们就是你的客户。多花一些时间深入了解客户，对管理者来说是非常重要的，因为你需要将这些信息传达给自己团队的工程师们。同时，这样也会帮助你搞清楚哪些技术工作对客户来说最具直接影响力，这样你就可以将工程力量投入于这些方面。切记不要成为依赖产品经理的技术管理者，如此，你就完蛋了，就不是一个真正的技术人。

作为管理者，无论从产品角度还是从技术角度，你都要超前思考。提前了解产品的规划方向有助于你规划技术发展路线。很多技术项目的出发点都在于能在未来更快开发新的功能。这一切都要从你理解产品团队的产品路线图开始，同时也需要你多花一些时间理解新技术，以便理解如何用技术来应对产品功能和线上运维的需求。

技术管理者应该在项目结束后进行复盘工作，核查项目开始时的假设是否符合现实。系统重构之后，团队的效率是否有所提高？产品的新功能上线后，客户行为是否按照事前假设改变了？在这次 A/B 测试中，你到底学到了什么？如果能在团队中培养复盘的习惯，你就能从自己的决策结果中进行自我学习。

好经理 VS 坏经理

在讲这部分内容之前，我们先来看两个案例：

第一个案例

技术经理 J 的团队工作压力超标。团队中的每个人都认为 C 成员应该赶紧开始某个大型系统的重构工作，但是他却经常在自己喜欢的小项目上花时间。在收到团队关于 C 的反馈之后，J 召开了一个工作会议，要求大家投票决定团队应该停止开发哪些项目，以便降低工作强度。不难预料，除了 C，每个人都对 C 的小项目投了反对票。C 事先从来没有在这件事上收到过 J 的反馈，他一直以为自己做的事情是对的。案例中 J 的团队之所以感到压力大，一部分原因是 J 没有代表团队推掉过多的来自其他团队的工作，他不愿意对新项目说不，也不懂得增加新的团队成员，以便降低工作强度。J 虽然易于相处，但他不善于直面冲突，不不懂得如何主动解决问题，最后导致团队工作强度过大，优先级不明确，团队成员心生不满。

第二个案例

技术经理 L 团队的压力也不小，他的团队中同样有一个类似于 C 的人。之前，L 也批准过 C 的项目计划，但是目前的团队优先级已经发生了变化，C 的项目计划也必须随之变动。在与 C 的一对一会议上，L 解释了团队目前工作重点的变化，明确告诉 C，团队需要他帮忙进行系统重构。C 对此当然不是很开心，L 也觉得很无奈。然而，L 知道作为团队的管理者，她需要确保团队成员专注于那些重要的项目之上。L 知道该项目对团队具有长期价值，在对外争取更多资源的同时，她确保会将这些信息传达给整个团队。她带领团队给工作进行优先级评级，帮助团队采用结构化的方式来解决技术选型上的冲突。L 团队对他的评价是严厉，但是不乏公正，虽然团队中的意见冲突在所难免，但是整个团队具备良好的协作氛围，能够解决这些问题。

以上两个案例，明显能看出来 J 不能很好地解决冲突，反之 L 做到了对冲突的及时化解。虽然 J 具有民主管理的风格，将权力赋予了团队，但事实上由于他不敢说不的做法以及对决策缺乏担当的行为，导致团队中的每个人都信心不足。

如何处理冲突

从上面两个例子我们可以清晰发现，好的技术经理和坏的技术经理的最大区别就是避免冲突以及消解冲突。从我的个人管理经历，这里关于如何处理冲突，在处理冲突时应该做什么不应该做什么，给到大家一些建议：

不依赖调查问卷/投票机制

如果一个管理者想发现问题或者做决策的时候，靠的是在团队或者公司内部通过调查问卷/投票的方式，追求事事在团队中达成共识，听起来在道德上很好的做法，但是这高度依赖于每个人在投票过程中都能做到真正的公正公平。要知道，人性使然，并不是每个人都对投票结果同等关注，也不是每个人都能了解所有背景信息，同时在一个包含不同角色不同资历的团队中，想要通过投票这种方式来达成共识，天方夜谭。

作为一个管理者想要培养团队自我决策能力的时候，首先要对评价决策的标准达成共识。从在团队中推行对项目目标、项目风险的深入理解开始，建立一套针对决策的评估标准。当你把某项决策权交给团队中某个成员时，应该要明确说明在决策之前需要征求谁的意见以及将决策结果向谁汇报。

不要掩盖问题

避免冲突的另一种表现方式是无法在问题出现初期及时解决问题，而拖了过长的时间。作为一名管理者，如果在绩效评估时你要给某位成员提供负面反馈，那么这对他来说不应该是完全出乎意料的。确实有可能一些小问题，不到绩效评估的时候你想不出来。但是如果某人的工作方向有大问题，就应该在你意识到这一点的时候尽早让他知道。如果你在项目评估的时候，通过阅读同事的反馈才发现他的工作有问题，那就太糟了。要么这是因为你没有对团队成员的工作给予足够的关注，要么就是你在一对一会议中没有留出足够的时间来讨论团队成员之间的冲突。

直接解决冲突而不是制造更大的风波

这两种处理方法的区别很大。团队成员需要一定的机会来表达自己的不满，但是要注意一般性的抱怨和人身攻击之间的区别。要运用你的判断力来决定自己需要解决哪些问题，而哪些问题不应该被继续关注。这里的关键是，这个问题是否会一直持续存在？你自己是否也注意到了这个问题？这是一个所有的团队成员都普遍面对的问题吗？这个问题中是否掺杂了权力或者偏见的因素？你的目标是，识别出那些影响团队协作效率的问题，而不是给每个团队成员进行心理咨询。

不要将问题推给其他团队

具有讽刺意味的是，习惯于逃避自己团队内部冲突的管理者经常向其他团队主动挑起冲突。这种管理者对自己的团队非常在意，当面对自己认定的外来威胁时则非常暴躁。当出现某种跨团队的问题时，这种管理者会拼命保护自己的团队，把问题推给其他团队，给自己的团队要求补偿。有时，这种行为其实反映了他自己团队中存在的某种隐藏已久的问题。正如我的一个朋友说的：“有 10% 不足的地方我也不敢和自己团队的成员说，因为我怕他们会因此忽略那些90%做得好的地方。于是我就拿其他团队当出气筒，对他们的问题吹毛求疵。事实上我真正想要的是让所有人都对自己的工作负起责任来，我应该用一种更好的方式向内、向外传达这个信息。”哈哈，这种我好像太有深刻印象了。

善待团队成员

与别人良好相处是每个人的天性。我们中的很多人都认为，获取其他人好感的办法是，展示自己是一个易于相处的人，最终目的是和每个人和平共处。但是作为管理者，你的目标并不是做到与他人易于相处，而是友善待人。易于相处是你在与陌生人、不太熟的人相处时的通行证。当别人问你心情如何的时候，易于相处的人会说我挺好，而不会说我心情糟透了，别来烦我。在日常沟通中，这些都是好事。但是对一个管理者来说，随着工作关系的深入，友善待人会变得更为重要。这意味着，在你告诉某个成员，其晋升不符合条件时，随后说明他未来要想晋升所需要做的事情。与之相比，如果告诉某个人：“你可能会晋升。”然后等着看他的笑话，就是很不友善的。同样地，直接告诉某个人，他在会议中的行为影响了团队协作也是一种友善的行为。这样的谈话很尴尬，但是很有必要，因为作为管理者，你的一部分职责就是进行这些谈话。

不要害怕

人们对冲突的逃避通常来源于自身对冲突的恐惧。我们都害怕自己需要做出困难的选择。我们担心自己会显得要求过多。我们担心向别人提供负面反馈之后，其会辞职。我们担心团队成员不会喜欢自己，或者担心自己做出选择之后会失败。恐惧是每个人与生俱来的，事事保持高敏感度其实也是一件好事，但是不要害怕。

保持好奇心

多思考自己的行为是克服恐惧的最好方式。当你将某项技术决策权推给团队成员时，是因为他们是做出决策的最佳人选，还是因为你知道做出必要的但是小众的决策会导致团队成员不喜欢自己？你有意逃避某个同事时，是因为他真的难以共事，还是因为你担心讨论过程中会证明自己是错误的，希望等着问题能够凭空消除？拖着不给团队成员提供负面反馈，是因为他最近的状况真的不好，还是因为担心提供这些负面反馈之后，他会开始讨厌你这个经理？遇事多思考，就能避免一些不必要的冲突发生。