管理 一

 

 

恭喜升职为中层技术管理人员！在不同的企业里，中层技术管理人员的具体职位名称有所不同。在微软、IBM这样的大型企业里，中层大致对应着部门经理或产品线负责人这样的职位。而在互联网企业如BAT，技术总监、高级或资深研究员实际担负着中层管理的职能。无论如何，中层技术管理人员的共同特点是：管理团队的规模在100人以内、有负责技术团队的资源流向和人事流动的决定权，但与企业仍保持双向自由选择的雇佣关系；对企业的核心战略有技术话语权和影响力，但并无决策权。中层和基层技术管理人员的最本质区别在于，中层负责战略执行，而基层负责日常交付。用通俗的话说，中层要考虑怎么把老板的想法用技术手段在一定时间内变成现实，具体每天的活可以交给基层队伍去完成，而由中层负责检查和指正。遇到基层搞不定的或者需要协调的问题，中层要出面解决。另外，中层管理人员还要负责技术团队的建设和培养。

中层技术管理人员的思想定位

新官上任的中层技术管理人员首先要弄清楚的一个问题，就是向谁负责。这个问题弄不清楚，工作就无法开展。企业的情况千差万别，但有一点是任何中层技术管理人员都需要首先明确的：要对直接业务上级负责。中层可能本身又分成若干级别，无论如何，下级负责人不要越位替业务上级谋政，每个中层都要具备强烈的服从意识。这包括几个方面：首先，上级交给的战略规划，自己应该负责去想办法用掌握的技术资源加以落实，不要先对战略规划本身采取整体怀疑的态度；其次，在战略执行实务上，如果上级有明确的指导意见，自己应该考虑在这一部分已确定的前提下，如何通过安排其他部分来完成战略规划；再次，在自己的意见与上级的意见相左时，首先考虑自己如何调整。除此之外，任何答案都是错误的。

“对公司负责”，错！董事会才对整个企业负责，如果他们决定走一条错误的道路毁掉整个企业，那也是他们自己的损失。但在此之前中层技术管理人员只要一天不离职，就应该坚决地带领自己的技术团队在这条路上稳稳地走下去，当然如果发现情况不对，应该向直接业务上级汇报。

有人会说，这种说法充满奴性啊，现在不是都讲团队自治、讲技术创新吗？你这样的观点和意识太陈旧。

其实并非如此。团队自治是很好的，但治什么呢？这需要存在强烈的共同目标才能执行到位。要形成这样的团队，就不能没有充分理解企业的战略目标，并知道要达到这样的目标应该在一段时间内做什么，在下一段时间内又要做什么的人。中层技术管理人员接受的技术任务，绝不是那种凭一段时间的热情就能够完成的。这样的技术任务往往是“10个月内完成公司网站的建设”，“半年内上线产品的Android 4.2适配版本”，涉及到数十万行代码、超过100人月、跨越整个产品生命周期的事。而靠团队自身是难以产生统一行动的驱动力，来把技术任务逐一分解并一一落实的，更不要说涉及到跨功能部门沟通了，所以自治模式严重受限于团队和任务的规模。

说到技术创新，我反而要说：服从约束更加有利于技术创新。中层技术管理人员是被赋予了相当程度的创新自由的，但这些创新要用对地方。如果上级说，预算只有20万元，但某人却一定要50万元才能完成任务执行，因为要采购专业软件并招聘相关操作人员在他来看是必要条件。但是，另一个人却认为采用一些开源替代方案，并聘请一些有经验的人士在有限时间内对现有人员进行技术培训和指导，就可以在预算内完成执行的话，你认为哪个人更有创新思维呢？必须要承认，所有的中层技术管理人员都在戴着镣铐跳舞，而且新任者必然戴着更重的镣铐。但如果你想减轻这镣铐，就先运用创新思维证明你可以跳出更好看的舞吧，然后你再说如果自己戴着轻一点的镣铐可以跳出更多花样的时候，就会有人信了。

技术团队的建设和培养

技术战略的执行靠的自然是技术人才。技术团队的建设和培养是要靠中层技术管理人员来完成的，任何成功的中层技术管理人员必然有自己的技术班子。但如何扯起这么一个班子，是很见水平的。前面说过，中层技术管理需要负责战略执行，而要执行战略不比做一两个具体交付任务，其复杂和未知程度要远远高出许多。

在未来时态下建设和培养技术团队。这是中层技术管理人员对于自己负责业务的理解深度决定的。例如，如果负责一个手游产品，而游戏的题材并非局限于只能在手机上玩，要从一开始组织团队时就考虑游戏转型的可能，有意识地积累一些在PC游戏端和页游方面有一定经验的人手，并在游戏策划和技术实现时尽可能不要把一切都绑定在手机平台这个假设上。这样，一旦产品真的要转到别的平台上去，技术团队就不会感觉非做伤筋动骨的调整才能服务于全新的战略了。在工作一成不变时，加强相关领域的学习，往往会在战略突然发生剧烈调整时收到极高的回报。合格的中层技术管理人员，永远会在思考这样的问题：我未来可能会要执行什么技术战略，我现在的团队能够应对吗？如果不能，我还差哪些方面？差的这些方面，是必须引入新人，还是要现有人员学习和培训？这样，在团队建设的每一时刻，都是有逻辑的，至少不会失控。而在引入团队新成员时，也自然而然地会把人的潜力、人的学习意愿纳入考量，而不仅是现在拥有的技术和经验作为唯一的考察因素。

要为技术团队大胆引入多种人才。很多技术团队面临的大问题，不是成员太不会干活了，而是太会干活了——他们是如此地会干活，以至于连要干什么都搞不清了。技术团队里面，一定要有润滑剂这样的角色，他们的任务不是直接产出工作量，而是让所有人都能够明白自己每天工作的意义所在，以及各项工作应该分配的比重，甚至工作之外还有什么可以适当调节一下身心的乐趣。这样的工作并不一定非要专职的人来做，但在引入新人时，不妨可以从性格和业余爱好等诸多方面综合考虑一下，尽可能地让技术团队里配置多种多样的人，而不是所有人都一副面孔。这样做的目的，是为了提高技术团队的韧性，在受到压力时，不至于由于某个方面的刚性因子过大而让整个团队一起垮碎。

要敢于与其他技术团队互通有无，不要让团队跟自己的姓。有不少中层技术管理人员舍不得自己培养出来的团队，尤其是核心人员，走到哪里都带着。抛开离职时带走人员的职业道德问题不谈，这样做有很多弊端。首先，这样的做法剥夺了别人拥有独立发展空间的权利，为什么别人要永远在你手下做你的二把手？我就对此有深刻的体会，我从某公司离职去了下一家，然后过了半年以后又和我原先的一个下属吃饭。在谈到我们过去一起做的业务时，我发现他的进步简直大得让我吃惊：这个原先几乎事事要问我意见的人，在我离开放手让他独立经营的半年之间，已经有了极好的独立性，不仅能战斗而且能指挥了。从此以后，我就下定决心，自己培养出来的技术团队，就在原地服务，一个人都不带走。其次，有些人只要由于业务调整要把自己培养的人调走，或是要把自己不熟悉的人调入，就各种不开心，觉得不公平。中层技术管理人员应该超越这种小家子气，要反过来看这个问题：自己培养的人去了别的地方，等于是要播撒自己的管理理念。而别的团队，甚至是在内部竞争中位于对抗地位的团队如果派人到自己团队里面来，这也正是一个学习的机会。

有一次，在我带的手机测试部门里，就被安排接收了几个做手机客服的同事。结果，我发起了几次内部培训，让他们给我们讲手机客户都投诉什么，用我们团队成员的话说，“这比在实验室里关门做一年实验都要生动、具体”。反过来，我们给他们讲手机各个部件的测试原理和方法，他们和过去的同事交流时，也发现把这些内容融入客户支持材料比背几套问答模板要有用多了。结果，过了四个月他们收到要调回原部门的意向时，竟然都表示不愿意走了。于是，我趁机组织了一个“手机测试和客服部门沟通例会”，自此我们团队的测试效率明显提高，而客服团队收到投诉率明显降低。一年不到的时间里，我们两个团队都成了公司的明星团队。

中层技术管理人员的自我修养

中层管理阶段是每个技术管理人员都要好好把握的。原因有三。

首先，中层管理是个极其关键的跳板，从管理科学的角度来看，直接管理的人数一般不宜超过7人，就算管理能力超强算10人，中层管理所带领的团队一般都大大超过这个数字。所以，从管理分类的角度来看，中层管理是接触和学习间接管理的重要阶段。而掌握了间接管理的要素，实质上从管理的日常实务来看就没有什么新鲜的东西了——管20个人要这样管，管两万个人还是要这样管：实际上就是要管理你直接指挥的那7到10个人，然后把管理任务递归地落实下去。

其次，无论愿不愿意承认，中层管理对绝大多数管理人员来说都是职业生涯的最后一站，是要做到退休的。升到高层管理职位，不仅要靠实力和成绩，还取决于太多偶然因素构成的综合机遇。所以从这个阶段开始，要准备长期的磨练甚至反复。

再次，中层管理的职业生涯的时间阶段往往和人生进入成熟期的经历是重合的，对于技术管理人员来说，是自己的技术积累逐渐转化为个人解决问题思路的深化、对于复杂局面的判断以及管理风格的形成这些无价特性的关键时期。

那么，中层技术管理人员应该着意锻炼自己的哪些素质，为新的机遇和挑战做好准备呢？

首先，中层技术管理人员应该摆脱幻想，习惯于把工作的基础建立在收集信息和反复分析之上。促成了这个要求的，还是工作的长期性和复杂性。例如，某个产品的返回状态信息里面有一个拼写错误，是不是直接在代码里改一下然后重新部署一下就可以了呢？基层开发经理可以这么想、这么做，但如果是中层部门经理就不能这么轻率。如果仔细收集信息就会发现，这个返回状态有大量的关联测试代码，只要修改了就会引发大量的测试脚本阻塞，连带着停止部署流水线，修复所有问题的时间会造成错过运营上线的排期。所有的这些信息，都是一点一点从各个不同的基层经理甚至一线程序员那里报告回来的，最终才能做出正确的判断：这个问题应该修复，但要考虑到回归测试用例的修改时间，以及排期提前量，而客户并未就此拼写问题提出任何抱怨，所以优先级应该排到较低的级别。

这样的问题，可以说在中层管理人员这里还算是最简单的一类，属于有明确答案的技术问题。那么，要判定一个快量产的机型的某个硬件组件是否应该更换型号或供应商，一个已经有上万名用户的函数库是否应该合并某个提高特定场景性能但会引发重新编译的实现，这些问题其实没有正确答案，只有反复权衡。更有甚者，某个技术人员是应该由于某次贡献加薪，还是一次性奖励？某个面试者解题的路子很野，但答案居然是对的，要不要发offer？这些就更加棘手，需要收集的信息更多、渠道也更需要广些。中层技术管理人员处理信息的一般原则应该是花费尽可能长的时间收集和分析信息，而将输出信息的时刻尽可能延迟。一定要记住技术规律是没有什么侥幸空间存在的，人心更是复杂多变。知之为知之，不知为不知。只要是不知道的信息，就是凭空想象出来的。以一个人的力量想知道所有的细节是非常困难的，需要持续投入时间和精力。但具体到每一个技术决定，需要掌握的信息则是有限的，尽管不能知道所有需要的信息也是在所难免。此时，就要尽可能地降低凭空想象来做决定的成分。所以，晚一秒钟做出决定，就多一秒钟来收集和分析信息，就少一分凭空想象造成错误决定的风险。

其次，每个中层技术管理人员都要锻炼自己的技术表达能力，要能够把涉及多于10个技术要素、相关人等、人与事的关系、人与人的关系和事物发展的逻辑等来龙去脉讲得一清二楚、井井有条。并且，要讲得通俗易懂，要让只有5分钟耐心的、和要讲述的内容毫无关系之人都能听懂，最好能被打动。这一点，是非常关键的。我参与过多次年度汇报，大量的中层管理人员做的汇报都有较大的改进空间。讲了半天，除了他和自己团队感动了，别人都还是一脸茫然。其实，别人能看到你做的工作，就是你能讲明白的那部分工作。说到底，这不是临时抱得了的佛脚。没有执行到位的工作，任何人都编不出可信的故事，而且几个简单的问题就马上要露马脚了。可是，如果自己的辛勤工作要为蹩脚的表达买单，对于大多数中层管理人员而言，也就意味着上升通道就此关闭了。

用服务的心态为自己定位，用培养的手段为企业纳才，不放弃任何管理创新的机会，锻炼快听、多想、慢说、表达到位的职业素养，这是中层技术管理人员不断成熟的诀窍。要做到这些，离不开中层技术管理对于技术的敬畏，和不断的技术学习。在本刊9月期《技术团队新官上任之基层篇》一文中，我曾说过，技术行业是一种终身职业，一旦入行，就要学习终身。这一点同样也适用于中层技术管理人员。停止学习，就意味着职业生涯的死亡，这决非危言耸听。下一期，我们将和自己创办企业，以及受到机会女神眷顾，成功晋升到技术高层管理职位的同学们分享更多更精彩的内容，欢迎阅读和反馈。

 

 

技术团队的管理人员身负技术和管理的双重使命，有着与众不同的成长路线。绝大多数情况下，在成长路线的第一步，是“技而优则管”，亦即由于表现出了出众的技术交付能力，优秀的技术人员被提拔到了基层管理岗位以承担更加重要和关键的交付任务。

众所周知，这并不是技术人员的唯一职业成长路线，大多数人都会在所谓的个人贡献路线上持续发展，走到管理岗位的转折点是少数人的路线。这条路并不好走：一方面，一旦承担了管理使命，工作内容和期望就会发生性质的转变，需要思考和学习一些全新的东西，这对于新官上任的技术管理人员来说挑战着实不小；另一方面，原有的技术使命变得更重了，如何能够运用好管理杠杆，不辱使命地完成技术任务，更是缺乏经验的技术管理人员很容易陷入两难的谜题。

技术管理路线从哪里开始

这个问题貌似非常可笑。技术管理路线不是从被提拔到技术管理岗位的那一天开始的吗？其实这么想就大错特错了。技术管理从来都是先有了管理之实，才会给予管理之名的。管理，顾名思义，包括“管”和“理”两个部分，而这两个部分都有着十分具体的工作内容。“管”的核心，在于对人员和资源施加影响和约束，使之向着既定的目标靠拢。而“理”的奥秘，在于组织协调人员之间的关系，减小摩擦阻力而激发合作动力甚至潜力。一言以蔽之，管理的实质，在于发挥团队的力量来完成 目标。也就是说，只要一个目标并非通过自己个人的力量，而是假借了别人的力量来完成，这就是管理路线的开始了。

这也是管理魔力的所在：一名 优秀的技术管理人员，就仿佛是长了三头六臂，既能够考虑到技术设计的方方面面，又能够把这种设计落实成以健壮漂亮的代码、精美易用的界面为基础的技术产 品。这不是因为他自己的精力变得无限了，也不全是因为他的技术本领变得高强了，而是因为有很多人在他的影响和组织下，向着他制定的统一目标在各显神通。

只要一名技术人员，他不仅是在一个人完成自己被分配的任务，而是在影响和组织不止他自己的其他人共同完成任务，他的工作角色中就已经包含了管理的成分。也只有事实上已经在从事管理工作、积累了管理经验并表现出一定管理天赋的技术人员，才有可能最终走上技术管理岗位，成为一名专职的技术管理人员。

这也部分地回答了“如何才能升到技术管理职位”的问题。想成为开发经理吗？那就不能满足于只是完成每天领来的那部分开发任务，而要思考这样的问题。

• 首先，我开发的这部分代码在整个项目里发挥着什么样的作用？
• 其次，我是不是可以把项目中至少我负责的这部分代码的上下游拉下来看一看是怎么回事？
• 再次，我理解了一个更大的逻辑以后，是不是能够和更多的开发人员坐下来商量一下怎么可以共同做一些改进，使得大家的日子都好过一点？还有，我是不是可以看一下测试人员是怎么来测试我写的代码，用例是什么样的？而运维人员又是怎么部署和升级的，遇到生产环境中的问题是怎么解决的？我可以多开发一些工具来改进 交付流水线吗？我需要和几个人一起筹划这件事？

当开始这样思考并着手做事时，你就开始向技术管理职位迈进了。

不要做什么

技 术管理当然是内容非常丰富多彩的一个课题，要做什么、该怎么做，可以写出许多书来。但是，也许像任何踏进任何一个内容丰富的领域一样，先弄清不要做什么也许反而是很关键的。毕竟职业发展并非一日之功，刚刚入行时犯一点小错也是在所难免，但如果有方向性的问题没有弄清楚，就比较糟糕了。

不要去模仿乔布斯。我是说，也不要去模仿任何当下出名时髦的IT商界领袖。这里面有几层意思。

• 第一，基层技术管理人员往往除了管理职能以外，还有相当具体和繁重的一线技术的个人贡献期望。此时，如何把手头的短期工作用技术手段加以实现还是主要矛盾 所在，管理在这个阶段往往还是以提升技术效率为目的的辅助手段。在这个阶段，主要以全局战略和大胆创新为主要特点，高层技术管理思想和方法对于基层技术管理人员的直接参考意义不大。
• 第二，一个企业的成功往往有多方面的因素，绝不可能仅仅是技术因素促成了全部的结果。另一方面，当企业被光环笼罩时，无论是领导人还是企业的的传记作者都不免自觉或不自觉地夸大成绩方面而忽略甚至避而不谈其阴暗面。但如果片面夸大技术因素或成功因素，而忽略其可能带来的负面效应，哪怕只是很小的一方面，都 可能会导致适得其反的局面。
• 第三，也是最重要的，每个人都只能以自己的方式成功。应该对于自己耳听目见的信息，以及综合用心的判断抱有信心，只有自己总结出来的经验才能灵活运用，真正能够达到卓越程度的技术管理者无一不是自己摸索出来的管理之路。

不要去做职业经理人。更不要去学厚黑学，基层技术管理人员尤其没有这样做的生存空间。技术行业是一种终身职业，一旦入行，就要终身学习。IT技术行业，就更是如此。

试问，如果一个开发经理自己都不能够在下属遇到技术问题时为其解惑，又如何谈得上去影响和组织技术人员，使其发挥团队力量？又如何能够担负技术难题攻关的责任？技术人员是非常特殊的人群，其最显著的特点是生产力强大，但沟通力低于平均水平。

所 以，普通的职业经理人只运用沟通工具上传下达，是完全不能实现技术管理目标的，因为技术人员的显著特点就是在得不到适当信息输入的前提下，没有足够的意愿 达成沟通。并且，即使沟通已经很充分，也需要相当的技术理解力，才能将沟通的成果加以消化和落实。而这些，也正是技术管理人员独有的用武之处。

不要立刻施政。《谁说大象不能跳舞》一书中，IBM的新CEO郭士纳在走马上任的第二天就打破陈规，宣布新政。对于临危受命的高层管理人员来说，也许这样做有其必要性。但坦率地说，其实这可能并非最好的做法。而对于刚刚任命的基层技术管理人员来说，也许最重要的就是按捺住自己自以为是——也许出发点并不坏 ——的一肚子改革方案，而要耐着性子和团队一道做一段时间最无趣、最底层的“脏活累活”，真正了解到团队难在何处，以及需要怎样的帮助才能摆脱困境或做得 更好。

这是必须要做的、绝对不能省略的环节，无论这新上任的技术管理人员是原先从这个团队提拔上来，还是空降而来的。根本原因在于，专职技术管理人员是一定需要时间对于团队和技术产品做出深一步了解，而不可能瞬间无师自通的。即使对于若干技术细节已经有了专家水平的了解，但必然对于其他的部 分，还是需要相当的时间才能熟悉，进而才能与原有的知识融会贯通。

非技术管理人员瞎指挥，虽然可恶，但总算情有可原。但如果技术管理人员不懂装懂，给技术团队带来伤害，这真是罪无可恕！千万不要搞什么新官上任三把火，这除了烧掉自己的锦绣前程之外，别无它益。

打开思路，好好学习

成为一名基层技术管理人员以后，要着手做三件事：第一，要继续学习技术相关的业务知识；第二，要打开技术工作的思路；第三，要规划自己未来的专业发展路线。

很多优秀的技术人员，升任到管理岗位以后，便放慢了技术本身的深造和相关业务的学习。几年下来，人就基本上废了。而学习如逆水行舟，不进则退。此时再要求进 步，就难上加难了。但是，管理不是要别人做事吗？为何自己还要继续精进？没错，管理的实质在于借助他人的力量，将每个人的生产力加上团队合作的放大系数， 达成生产力大大提升的结果。但管理从来都不是发号施令这么简单，技术管理就更是如此。

技术人员可不是傻子，行家一出手，就知道有没有。任务下达、分工安排，甚至是一个小小流程的细节，技术人员心里都有一杆秤，在度量着自己的管理人员到底靠不靠谱。如果一个开发经理要求自己的员工“写出没有 Bug的代码”，此言一出，在专业技术人员的心中他就威信全失了。相反，如果一个敏捷教练能够准确地指出“在这个Sprint里面，我们把内嵌的SQL语句替换成了对应的API调用，这对于我们客户的安全性是一个很大的提升，防止了注入的风险并使得实现具有了弹性”，技术人员又怎能不对他肃然起敬？向管理 要效益，这是人人会说的话，但技术管理要取得效益，就体现在每一次的代码签入、质量评审、交付上线、运维配置上。

这一个个的活动，以及真正动手与它们打交道的人，正是需要基层技术管理人员用心去经营的对象。而这无不要求更高效、更全面的学习。更有甚者，基层技术管理人员往往是技术部门和其他部门，甚至企业外部的技术接口，而技术语言在更广阔的世界中是需要翻译的。基层技术管理人员往往面对这个新职能，会不知所措，而唯一的办法，只能是从小学 生做起，听听业务人员怎么描述他们的专业工作，甚至他们眼中的技术产品。能否立足技术、精通业务这一点，往往就是基层技术管理人员拉开差距的关键所在。

一线的技术工作，往往从方法到结果都有较大的限定性。而基层技术管理人员，第一次有了具体技术方案的调整权力，以及资源方面的一定自由。权力和资源，这是每一个管理人员都必须去想办法争取的核心利益所在。

管理人员如果没有一定的野心，这对于企业来说其实是非常不利的。可以说，正是管理人员想要争取权力和资源的动力，使得他们绞尽脑汁地优化自己的管理思想和方法，从而给企业带来了活力。但也正是他们争取权力和资源的动机和手段的差距，使得他们归属到了不同的梯队里。

基层技术管理人员，玩权术是绝对玩不过别人的，但也不能以此为借口，就因循守旧固步自封。须知，如果不是资深技术人员从事了技术管理岗位，那些岗位就必然是由技术不过关的人员占据，这对于团队和企业都不是好消息。

其实，权力和资源只要是出于正当的动机和合理的用途，就是为所有人造福的必要基础。那么基层技术管理人员如何争取到更多的权力和资源？办法很多。

• 首先，要对自己和团队做了哪些工作，做好详尽的记录和归档。这样，不仅对于技术工作的连续性是一个很好的保证，也是在整理和表述团队的技术成绩和做出成员业绩评审时的最有力材料，更可以在未来申请更多资源，承担更大责任时做到胸中有底、心中有数。
• 其次，权力和资源在运用时要节约，申请时要留有余量。有形的招聘、采购时，节约经费这个好理解。但在汇报工作时，注意汇报材料的合理性，不浮夸更不造假，从 而积累无形的信任；在为手下员工安排工作时，能够考虑到合理安排进度，造成有一定的压力但不至于形成焦虑的程度，并在遇到实际困难时予以解决，等等，从而积累无形的安全感和凝聚力，这些能力就需要时间来培养了。

从根本上说，一切皆是经营的结果，多站在老板和员工的角度来思考他们的难处，利用自己手里的权力和资源，尤其是团队的技术优势来为他们排忧解难，这是基层技术管理人员成长的阶梯和秘诀。

当然，并非每个人都适合做管理人员，基层技术管理人员如果发现自己从事管理工作时困难太多，其实也是并不一定非要在这条道上走到黑不可的。如果实在觉得自己不适合管理，那么勇敢地放弃并回到个人贡献的路线上来，也不失为一种不错的选择，而且前途是一样光明的。

但如果权衡的结果是迎接挑战，继续在技术管理的道路上前进，那当然就意味着有更多的东西要学习、有更大的困难要克服，当然也有更好的回报在等待。下一期，我们将和晋升到中层技术管理的同学们分享更多更精彩的内容，欢迎阅读和反馈。