摘要：对任何企业来说，中层管理人员都是极为关键的，因为中层是执行力的来源。可以说，一家企业有没有希望，只要看一下中层是精明强干，还是松松垮垮就全明白了。其中有哪些必须了解和掌握的知识和道理呢？
恭喜升职为中层技术管理人员！在不同的企业里，中层技术管理人员的具体职位名称有所不同。在微软、IBM这样的大型企业里，中层大致对应着部门经理或产品线负责人这样的职位。而在互联网企业如BAT，技术总监、高级或资深研究员实际担负着中层管理的职能。无论如何，中层技术管理人员的共同 特点是：管理团队的规模在100人以内、有负责技术团队的资源流向和人事流动的决定权，但与企业仍保持双向自由选择的雇佣关系；对企业的核心战略有技术话语权和影响力，但并无决策权。中层和基层技术管理人员的最本质区别在于，中层负责战略执行，而基层负责日常交付。用通俗的话说，中层要考虑怎么把老板的想
法用技术手段在一定时间内变成现实，具体每天的活可以交给基层队伍去完成，而由中层负责检查和指正。遇到基层搞不定的或者需要协调的问题，中层要出面解决。另外，中层管理人员还要负责技术团队的建设和培养。
中层技术管理人员的思想定位
新官上任的中层技术管理人员首先要弄清楚的一个问题，就是向谁负责。这个问题弄不清楚，工作就无法开展。企业的情况千差万别，但有一点是任何中层技术管理人员都需要首先明确的：要对直接业务上级负责。中层可能本身又分成若干级别，无论如何，下级负责人不要越位替业务上级谋政，每个中层都要具备强烈的服从意识。这包括几个方面：首先，上级交给的战略规划，自己应该负责去想办法用掌握的技术资源加以落实，不要先对战略规划本身采取整体怀疑的态度；其次，在战略 执行实务上，如果上级有明确的指导意见，自己应该考虑在这一部分已确定的前提下，如何通过安排其他部分来完成战略规划；再次，在自己的意见与上级的意见相左时，首先考虑自己如何调整。除此之外，任何答案都是错误的。
“对公司负责”，错！董事会才对整个企业负责，如果他们决定走一条错误的道路毁掉整个企业，那也是他们自己的损失。但在此之前中层技术管理人员只要一天不离职，就应该坚决地带领自己的技术团队在这条路上稳稳地走下去，当然如果发现情况不对，应该向直接业务上级汇报。
有人会说，这种说法充满奴性啊，现在不是都讲团队自治、讲技术创新吗？你这样的观点和意识太陈旧。
其实并非如此。团队自治是很好的，但治什么呢？这需要存在强烈的共同目标才能执行到位。要形成这样的团队，就不能没有充分理解企业的战略目标，并知道要达到 这样的目标应该在一段时间内做什么，在下一段时间内又要做什么的人。中层技术管理人员接受的技术任务，绝不是那种凭一段时间的热情就能够完成的。这样的技 术任务往往是“10个月内完成公司网站的建设”，“半年内上线产品的Android 4.2适配版本”，涉及到数十万行代码、超过100人月、跨越整个产品生命周期的事。而靠团队自身是难以产生统一行动的驱动力，来把技术任务逐一分解并一 一落实的，更不要说涉及到跨功能部门沟通了，所以自治模式严重受限于团队和任务的规模。
说到技术创新，我反而要说：服从约束更加有利于技术创新。中层技术管理人员是被赋予了相当程度的创新自由的，但这些创新要用对地方。如果上级说，预算只有20万元，但某人却一定要50万元才能完成任务执 行，因为要采购专业软件并招聘相关操作人员在他来看是必要条件。但是，另一个人却认为采用一些开源替代方案，并聘请一些有经验的人士在有限时间内对现有人员进行技术培训和指导，就可以在预算内完成执行的话，你认为哪个人更有创新思维呢？必须要承认，所有的中层技术管理人员都在戴着镣铐跳舞，而且新任者必然戴着更重的镣铐。但如果你想减轻这镣铐，就先运用创新思维证明你可以跳出更好看的舞吧，然后你再说如果自己戴着轻一点的镣铐可以跳出更多花样的时候，就会有人信了。
技术团队的建设和培养
技术战略的执行靠的自然是技术人才。技术团队的建设和培养是要靠中层技术管理人员来完成的，任何成功的中层技术管理人员必然有自己的技术班子。但如何扯起这么一个班子，是很见水平的。前面说过，中层技术管理需要负责战略执行，而要执行战略不比做一两个具体交付任务，其复杂和未知程度要远远高出许多。
在未来时态下建设和培养技术团队。这是中层技术管理人员对于自己负责业务的理解深度决定的。例如，如果负责一个手游产品，而游戏的题材并非局限于只能在手机上玩，要从一开 始组织团队时就考虑游戏转型的可能，有意识地积累一些在PC游戏端和页游方面有一定经验的人手，并在游戏策划和技术实现时尽可能不要把一切都绑定在手机平 台这个假设上。这样，一旦产品真的要转到别的平台上去，技术团队就不会感觉非做伤筋动骨的调整才能服务于全新的战略了。在工作一成不变时，加强相关领域的 学习，往往会在战略突然发生剧烈调整时收到极高的回报。合格的中层技术管理人员，永远会在思考这样的问题：我未来可能会要执行什么技术战略，我现在的团队 能够应对吗？如果不能，我还差哪些方面？差的这些方面，是必须引入新人，还是要现有人员学习和培训？这样，在团队建设的每一时刻，都是有逻辑的，至少不会失控。而在引入团队新成员时，也自然而然地会把人的潜力、人的学习意愿纳入考量，而不仅是现在拥有的技术和经验作为唯一的考察因素。
要为技术团队大胆引入多种人才。很多技术团队面临的大问题，不是成员太不会干活了，而是太会干活了——他们是如此地会干活，以至于连要干什么都搞不清了。技术团队里面，一定要有润滑剂这样的角色，他们的任务不是直接产出工作量，而是让所有人都能够明白自己每天工作的意义所在，以及各项工作应该分配的比重，甚至工作之外还有什么可以适当调节一下身心的乐趣。这样的工作并不一定非要专职的人来做，但在引入新人时，不妨可以从性格和业余爱好等诸多方面综合考虑一下，尽 可能地让技术团队里配置多种多样的人，而不是所有人都一副面孔。这样做的目的，是为了提高技术团队的韧性，在受到压力时，不至于由于某个方面的刚性因子过大而让整个团队一起垮碎。
要敢于与其他技术团队互通有无，不要让团队跟自己的姓。有不少中层技术管理人员舍不得自己培养出来的团队，尤其是 核心人员，走到哪里都带着。抛开离职时带走人员的职业道德问题不谈，这样做有很多弊端。首先，这样的做法剥夺了别人拥有独立发展空间的权利，为什么别人要 永远在你手下做你的二把手？我就对此有深刻的体会，我从某公司离职去了下一家，然后过了半年以后又和我原先的一个下属吃饭。在谈到我们过去一起做的业务 时，我发现他的进步简直大得让我吃惊：这个原先几乎事事要问我意见的人，在我离开放手让他独立经营的半年之间，已经有了极好的独立性，不仅能战斗而且能指 挥了。从此以后，我就下定决心，自己培养出来的技术团队，就在原地服务，一个人都不带走。其次，有些人只要由于业务调整要把自己培养的人调走，或是要把自己不熟悉的人调入，就各种不开心，觉得不公平。中层技术管理人员应该超越这种小家子气，要反过来看这个问题：自己培养的人去了别的地方，等于是要播撒自己 的管理理念。而别的团队，甚至是在内部竞争中位于对抗地位的团队如果派人到自己团队里面来，这也正是一个学习的机会。
有一次，在我带的手机 测试部门里，就被安排接收了几个做手机客服的同事。结果，我发起了几次内部培训，让他们给我们讲手机客户都投诉什么，用我们团队成员的话说，“这比在实验室里关门做一年实验都要生动、具体”。反过来，我们给他们讲手机各个部件的测试原理和方法，他们和过去的同事交流时，也发现把这些内容融入客户支持材料比背几套问答模板要有用多了。结果，过了四个月他们收到要调回原部门的意向时，竟然都表示不愿意走了。于是，我趁机组织了一个“手机测试和客服部门沟通例会”，自此我们团队的测试效率明显提高，而客服团队收到投诉率明显降低。一年不到的时间里，我们两个团队都成了公司的明星团队。
中层技术管理人员的自我修养
中层管理阶段是每个技术管理人员都要好好把握的。原因有三。
首先，中层管理是个极其关键的跳板，从管理科学的角度来看，直接管理的人数一般不宜超过7人，就算管理能力超强算10人，中层管理所带领的团队一般都大大超过这个数字。所以，从管理分类的角度来看，中层管理是接触和学习间接管理的重要阶段。而掌握了间接管理的要素，实质上从管理的日常实务来看就没有什么新鲜的东西了——管20个人要这样管，管两万个人还是要这样管：实际上就是要管理你直接指挥的那7到10个人，然后把管理任务递归地落实下去。
其次，无论愿不愿意承认，中层管理对绝大多数管理人员来说都是职业生涯的最后一站，是要做到退休的。升到高层管理职位，不仅要靠实力和成绩，还取决于太多偶然因素构成的综合机遇。所以从这个阶段开始，要准备长期的磨练甚至反复。
再次，中层管理的职业生涯的时间阶段往往和人生进入成熟期的经历是重合的，对于技术管理人员来说，是自己的技术积累逐渐转化为个人解决问题思路的深化、对于复杂局面的判断以及管理风格的形成这些无价特性的关键时期。
那么，中层技术管理人员应该着意锻炼自己的哪些素质，为新的机遇和挑战做好准备呢？
首 先，中层技术管理人员应该摆脱幻想，习惯于把工作的基础建立在收集信息和反复分析之上。促成了这个要求的，还是工作的长期性和复杂性。例如，某个产品的返 回状态信息里面有一个拼写错误，是不是直接在代码里改一下然后重新部署一下就可以了呢？基层开发经理可以这么想、这么做，但如果是中层部门经理就不能这么 轻率。如果仔细收集信息就会发现，这个返回状态有大量的关联测试代码，只要修改了就会引发大量的测试脚本阻塞，连带着停止部署流水线，修复所有问题的时间 会造成错过运营上线的排期。所有的这些信息，都是一点一点从各个不同的基层经理甚至一线程序员那里报告回来的，最终才能做出正确的判断：这个问题应该修复，但要考虑到回归测试用例的修改时间，以及排期提前量，而客户并未就此拼写问题提出任何抱怨，所以优先级应该排到较低的级别。
这样的问题，可以说在中层管理人员这里还算是最简单的一类，属于有明确答案的技术问题。那么，要判定一个快量产的机型的某个硬件组件是否应该更换型号或供应商，一 个已经有上万名用户的函数库是否应该合并某个提高特定场景性能但会引发重新编译的实现，这些问题其实没有正确答案，只有反复权衡。更有甚者，某个技术人员 是应该由于某次贡献加薪，还是一次性奖励？某个面试者解题的路子很野，但答案居然是对的，要不要发offer？这些就更加棘手，需要收集的信息更多、渠道 也更需要广些。中层技术管理人员处理信息的一般原则应该是花费尽可能长的时间收集和分析信息，而将输出信息的时刻尽可能延迟。一定要记住技术规律是没有什么侥幸空间存在的，人心更是复杂多变。知之为知之，不知为不知。只要是不知道的信息，就是凭空想象出来的。以一个人的力量想知道所有的细节是非常困难的， 需要持续投入时间和精力。但具体到每一个技术决定，需要掌握的信息则是有限的，尽管不能知道所有需要的信息也是在所难免。此时，就要尽可能地降低凭空想象 来做决定的成分。所以，晚一秒钟做出决定，就多一秒钟来收集和分析信息，就少一分凭空想象造成错误决定的风险。
其次，每个中层技术管理人员 都要锻炼自己的技术表达能力，要能够把涉及多于10个技术要素、相关人等、人与事的关系、人与人的关系和事物发展的逻辑等来龙去脉讲得一清二楚、井井有 条。并且，要讲得通俗易懂，要让只有5分钟耐心的、和要讲述的内容毫无关系之人都能听懂，最好能被打动。这一点，是非常关键的。我参与过多次年度汇报，大 量的中层管理人员做的汇报都有较大的改进空间。讲了半天，除了他和自己团队感动了，别人都还是一脸茫然。其实，别人能看到你做的工作，就是你能讲明白的那 部分工作。说到底，这不是临时抱得了的佛脚。没有执行到位的工作，任何人都编不出可信的故事，而且几个简单的问题就马上要露马脚了。可是，如果自己的辛勤 工作要为蹩脚的表达买单，对于大多数中层管理人员而言，也就意味着上升通道就此关闭了。
用服务的心态为自己定位，用培养的手段为企业纳才， 不放弃任何管理创新的机会，锻炼快听、多想、慢说、表达到位的职业素养，这是中层技术管理人员不断成熟的诀窍。要做到这些，离不开中层技术管理对于技术的敬畏，和不断的技术学习。在本刊9月期《技术团队新官上任之基层篇》一文中，我曾说过，技术行业是一种终身职业，一旦入行，就要学习终身。这一点同样也适用于中层技术管理人员。停止学习，就意味着职业生涯的死亡，这决非危言耸听。下一期，我们将和自己创办企业，以及受到机会女神眷顾，成功晋升到技术高层管理职位的同学们分享更多更精彩的内容，欢迎阅读和反馈。
作者高博
