关于技术管理的系列文章，这是第三篇。没有实践支持的理论，容易流于空想。为此作者特意设计了 20 个特定的场景，帮助你更好地去理解、落地技术管理这件事儿。这 20 个问题，不一定都适合你，但总有一个，是你已经遇到，或者即将遇到的痛点所在。想知道怎么解决吗？ 最近针对技术管理工作写了两篇文章，分别是《程序员, 这是你想要的技术 leader 吗?》和《别人家的技术 leader 是如何建设团队、管理人员、沟通工作的?》。读者针对技术管理提了很多问题，这里我对这些问题进行回复，既是出于对提出问题的朋友的尊重，同时这些问题也是很多朋友都可能正在遇到或存在的疑惑，书面回复比较容易扩大交流范围。一共 20 道问题，我尽量用平实的语言回答这些问题。
1. 我在小公司做了 2 年的 Leader，请问现在应该继续做下去，还是去阿里这样的大公司从程序员做起？ 我的看法是，无论去阿里做程序员，还是继续留在当前的公司做 Leader，本质上都没有错，更多应该关注你所做的事情，是否有技术含量？是否符合你未来的职业发展方向？这两点很重要，无论在哪个环境，千万不要习惯于安逸，这样就好比温水煮青蛙，慢慢地你会失去技术能力，进而失去成为或继续做技术管理的机会。
这一题我想多讲一些，因为，本质上我也是内向型的人。
外向的人天生善于交际，长袖善舞，更容易引起别人的关注，在团队中表现更加活跃，所以他们更容易获得成功，也更讨人喜欢；内向的人却不容易得到重视、关注，甚至快乐。
有些父母发现自己的孩子是内向的人，他们会觉得有点遗憾，甚至难过。还有一些会尝试改变孩子这种性格特点，更有甚者，会认为孩子有心理障碍。然而内向型人格真的是一种不太好的人格特质吗？美国有一本畅销书《安静，内向性格的竞争力》，作者苏珊. 凯恩列举了许多性格内向的成功人士，他们安静、稳重、深思熟虑，他们默默地带给这个世界许多改变。如果他们不幸被强制改变成外向的人，这个世界会少许多天才，多出来许多“病人”。
回到工作中。内向的人表现为非常沉默、内敛，几乎感觉不到他们的存在。他们可以把工作完成得很出色，但是对团队执行力或者在会议上几乎没有什么贡献。他们在一对一的时候能进行交流，但退回到人群里以后几乎消失了。
在会议上让他们发言时，当他们分享自己的意见或见解时，要给予正面的支持，这样可以逐渐帮助他们建立自信，让他们感觉到自己对于团队是有贡献的。找机会跟他们交谈，当面认可他们的贡献。与他们的交流要单独进行，通过一些小事情与他们建立特殊的联系，例如分享工作经验、交流管孩子心得。总之，想法设法建立更紧密的联系。
而作为一名 Leader，你在生活中可以继续保持自己内向的本质，但是在工作中，你需要能够做出改变，承担起所有技术管理者应该承担的责任，勇敢地面对你所需要面对的复杂环境和事物，积极地与员工沟通，积极而高效地解决遇到的难题。回到家，你依然可以是那个内向而细腻的你。
我觉得 Leader 没有好或者不好之分，只有称职和不称职的区别。一位称职的领导，他需要做好团队的向下管理、向上管理、对外管理、自我管理等四个方面，管理的最终目标是：“不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，都不要让你的上级陷入困境”。
作为一名 Leader，千万不要以为不让员工承担较重的工作负担就等同于好领导。在技术圈，好人不等于好领导。技术是需要实际工作环境进行积累的，如果不让他们参与到技术难度较大的项目里，那么他们工作几年可能都是在原地踏步，这样会让热爱技术、对职业发展有自己的规划的有志之士选择离开你，他们要的不是一个单纯的好人，而是一位能够教给他们知识、引领他们不断提升技术的 Leader。
有。在我过往的职业生涯中，我有遇到导致团队奔溃的奇葩，也有遇到由于没有及时搞定技术问题，导致领导层对技术能力不认可的情况发生。
先说奇葩这件事。我有遇到过一心想当“老大”，不择手段压制同伴的奇葩，也遇到过对人很粗鲁、思维方式很自我的奇葩，还遇到过到处借钱的奇葩。对于各类奇葩，换成现在的我，我一定会在第一时间让他们走，无论他们的水平有多高，都不会犹豫，也不会期望自己能够改变什么，他们的性格是受了家庭或者经历的严重影响的。让这些人尽快远离团队，这样整个团队都会轻松很多。在我作为技术管理者还不成熟时，我没有处理好，导致了团队的负能量激增，这是我的过错，不会再犯。
再说后面那种情况。对于从事技术管理的人来说，技术和管理的比重最好能够保持在 8:2 的状态，这里不是说只拿出 20% 的时间进行管理，而是需要你能够每天只用 20% 的时间做完应该用 50% 时间做的管理工作，只有这样你才能够有足够的时间处理技术问题、不断提升自己的技术能力。无论出现什么技术问题或难题，一定要第一时间引起注意，将这件事的优先级派到较高地位，第一时间带领团队成员分析问题原因、明确解决思路和方案，安排相应人员着手进行技术调研或测试、编码等工作，用最短的时间找到切实可行的解决方案，并付诸实施。
米歇尔在去年美国大选之前的民主党全国代表大会上，这样描述自己的想法，“When they go low，we go high.”。当你遇到你觉得很难相处的人时，你需要告诉自己，保持自己的职业素养，不要轻易被别人激怒、烦恼，依然保持一颗平常心，努力把自己的工作做好。
对于平级的人，你确实拿他没办法，我的建议是找你们共同的领导反映你的困惑，或是通过你的领导找到他们的领导，由领导层沟通。对于所有的管理类问题，我觉得首先要自我检查，确保不是自身的问题，然后是沟通，保持高效、简单的沟通，这样可以帮助你至少说出自己的困惑，最后是放松自我，不要被不值得的事情或人所烦恼，过好自己的每一天，全力做好自己的工作，不断提升自我价值，抽出时间陪伴家人，这才是你应该做的。
6. 技术为主的公司和非技术为主的公司，技术管理有什么区别？ 首先，技术为主的公司和非技术为主的公司，技术管理者所做的工作是有明显区别的，因此，对于技术管理者的技术背景也是有明显差异的。非技术为主的公司，团队领导可以不是程序员出身，他可能来自业务部门，也可能来自运营部门，只要他过往的经历可以帮助他 Hold 住这个岗位。而对于技术为主的公司，技术管理者如果不懂技术，那基本上参加会议时一句话也插不上，别人又怎么对你有技术尊重呢。
技术为主的公司，程序员很多。从许多方面看，程序员之间的差异非常大，只有很了解程序设计的人才能完全理解这一点，事实上，程序员之间的差异主要来自个人内在因素，而不是外在属性。微软公司的 Bill Gates、Adobe 公司的 John Warnock、FaceBook 公司的 Mark Zuckerberg 都没有犯这样的错误，因为他们本质上也都是程序员。这也是为什么我觉得某些大型软件企业需要变革的原因，个人认为，在科技界你最好不要让非技术出身的人担任 CEO。
一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度实现技术支撑，减少定制项目中大量更改代码、需要新增模块情况发生。此外，产品研发过程体系也需要按照业务实际时间要求变化，不要拘泥于一定要按照瀑布方式，或是敏捷方式进行管理，凡事都需要找到契合自己的方式。鞋合不合脚，只有脚知道。
确实存在这样的情况，技术开发人员不太愿意理解产品业务。我们要从另一方面来引导他们，每个人都会对自己做的产品有特殊的关注，如果你能不断地收集用户使用后的反馈，特别是正面的反馈，那样就可以激发起技术人员对于产品的热情。我听说双 11 时，阿里会在办公室挂上电子地图，动态实时反馈各个城市的销售量，这种方式会让技术人员很有让系统保持稳定运行的动力。
9. 总是控制不住情绪，产品有些简单问题，总是来问，怎么办？ 庆祝你的成功，在失败中寻找幽默。别太把自己当回事儿，你放松，你周围的人才能放松。享受乐趣，并始终保持激情。——Sam Walton，沃尔玛创始人
不要对别人过于苛刻，这样会让你控制不住自己的情绪，你会认为别人很愚蠢，但在你做出这样的判断之前，你应该学会理解别人，因为你没有站在他的位置上，他所承担的压力、所面对的困惑，是你所不了解。所以，首先学会和人沟通，学会理解别人，无论对方是你的上级、接口人，或是下级。
如果你觉得很多问题一遍遍地解释，那我觉得有必要抽象出一份资料，Word 或者 PPT 都可以，形式不限，每每遇到这类情况时，你就可以甩出文档，避免自己的时间被这类情况消费了。
亚伯拉罕. 马斯洛在 20 世纪中叶提出了需求层次模型。在 1954 年首次出版的《动机与人格》（Motivation and Personality）一书中，他将该理论引入了商界。马斯洛认为，人的需求可以按层次划分，从最基本的对事物和居所的需求，到最高的追求自我完善，在低层次需求尚未完全满足之前，更高层次的激励没有多少用武之地。
直到今天，需求层次理论依然令人信服，在理解人的动机和个人发展的管理培训中经常会引用它。事实上，马斯洛围绕需求层次理论所提出的观点，今天依然在促使我们不断改善工作环境，鼓励员工充分发展，自我实现。
一旦生理需求满足后，人们就会寻求更高层次的满足。佛雷德里克. 赫茨伯格在 1959 年出版的《The Motivation to Work》一书中描述了他认为的激励因素，包括成就、认可、工作本身、责任、发展，只有当这些都得到实现和满足时，人们才能得到真正的激励，这样来看，这些因素意义重大，代表着更深层次的成就。
回到我们的问题。我觉得，他们家老板开公司到底想不想赚钱了？搞了一个大锅饭环境，连基本的激励都不存在了，还怎么让员工做出成绩。
我个人觉得并不是以待在办公室的时间长短评判一个人的工作是否称职，我们需要坚持的是以任务结果导向为主要评判标准。对于重大问题，比如阿里的双 11，如果系统出现问题，那么意味着所有的供应商都有可能因为系统问题导致破产、失业，进而你的职业生涯也结束了。所以，我们还是要看自己所从事的工作的复杂性，如果确实需要，即便是通宵待在办公室或客户现场，我觉得也是必要的。
团队的技术氛围，我们可以依靠建立技术分享制度、要求资深工程师参与或主导开源项目等方式加强技术氛围，但归根到底还是要有需求。只有当你团队所负责的业务需求迫使你不断做出技术更新，你才会真正意义上去不断自我学习，进而形成浓重的技术氛围。人，都是被逼出来的。
13. 对于态度不是很好的员工，应该如何解决，沟通过几次，也没有效果。 表现很差的人给团队拖后腿的方式很多。他们占用了预算的一部分，但是却无法交付出有效的成果。其他人如果看到他们差劲的表现，也会消极得失去动力或者失去对你的尊重。表现差的人可能会影响项目的进度，从而对项目中的每个人都产生不利影响。他们也会占用会议中的大量时间。因此不论如何，这种情况必须尽快解决。
虽然很难开口，但通常，终止合同对你和员工都是件好事。很多表现很差的员工都知道自己很差。很少有人会看不到现实情况，还幻想自己表现很出色。他们每天上班和睡觉都背负这这个沉重的负担。对大多数人来说，负担会沉重到难以忍受。所以，当你最终直面他们，并开始终止合同的流程时，员工通常会感到一种放下包袱的轻松。很多人会选择离开，也有一些人会选择尝试绩效改进，如果选择后一条路，你一定要定期与这个员工会面，审查绩效情况并讨论结果。
14. 技术管理者的 Coding 能力需要有多强？ 这一题和第 6 题类似。对于技术为主的公司，如果你没有很强的代码编写经验或者能力，你实际上会缺少对于技术方向的把握、对于技术细节的指导能力，进而失去程序员对你的技术尊重，可能只剩下管理尊重了，也就谈不上合格的技术管理称呼了。
对于非技术为主的公司，例如银行，我听说有研发团队的 Director 是由测试出身的人担任，也担任得很好，这是因为他可以使用业务知识（可能是他工作之外积累的）、较好的英语能力，赢得客户的信任。
还是沟通。很多情况下，你确实没有直接的考核权利，那就和你的领导进行沟通，希望至少给予你参与考核的权利，即以他为主，以你为辅，这样你就能间接地参与所管理者的考核。万事，学会沟通，高效、有效地沟通。
16. 创业型公司给配了一些能力很差的程序员，让我来领导，怎么办？ 无论 Starbucks，还是台湾的一点点奶茶店，他们所雇佣的员工素养一般都较高，尤其是 Starbucks。正是由于这一点，造就了这两家公司分别在咖啡零售店和奶茶零售店的绝对优势，至少在杭州是这样的。
创业型公司，如果认为技术人员的投入太多，而转而选择能力很差的程序员，那么最终也会落得和上面所说的例子以外的其他咖啡或奶茶零售店一样，永远不可能做成行业领头羊，而是很容易被淘汰。这是一个科技的时代，只有拥有技术，你才有可能最快、最好地做出产品。
真正热爱技术的人是不愿意参与政治斗争的，因为那样会很耗费自己的精力，让自己深陷其中，导致技术不能深入研究。
我觉得避免卷入的最好方式是，成为技术大牛，成为一位让公司高管、中层所尊重的技术人员，用你的专业能力证明自己。
如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们去憧憬广阔无垠的大海。——Antoine de Saint-Exupéry
团队技术管理者工作中的一个重要部分是引导事情走向正确的方向，并确保团队成员之间以及团队之间有正确的沟通方式，这就需要协调团队成员之间、团队与团队之间工作。需要注意的是，引导 / 协调的最终目的是为了让事情完成，而不是把关注点放在如何完成。
对于一个团队管理者来说，要想最大化地利用自己的时间和技能，就要引导程序员自己做出正确的决定，而不应该自己就把决定做了。想要协调好所有人，你首先需要学会倾听别人的想法，只有理解了他们的困惑，你才能够把引导 / 协调工作做好。这样做，可以帮助下属员工培养技术、积累经验、建立自信，还能获得那些具体执行决定的员工的认同。
如果你发现自己经常需要讨论非常具体的命令如何执行，那说明你没能很好利用你的管理技能，或者没能赋予下属员工足够的权利。作为团队管理者，你必须指出大方向，然后做好充分的检查，以确保员工做出正确的决定和实现。及早检查下属员工做出的重要决定，否则当你想中途接入并修正时，员工可能已经做了很多无用的工作。这也是为什么我在“进度管理”一栏中强化自己的每天进度跟踪、讨论的重要性。
记住，优秀的主管要有足够的自制力，不在下属员工工作时瞎指挥。
领导是你的上级，所以你需要做好自己的向上管理。向上管理取决于你是否能够正确地理解你的老板，以及其他你可能间接或隐式汇报的人。如果你是向工程副总裁汇报，那么沟通和汇报可能是技术性的，如果你是向首席执行官或者产品副总裁汇报，那么你的汇报可能就要减少技术性，增加信息性，也许还要多加一些与产品相关的内容。除此之外，你老板的级别越高，你的报告就越要精简，越要注重大局，细节更少、局面更大，文字更少、项目符号更多。
对于一位对技术不敏感的领导，你应该去深入了解这位领导的擅长领域，或者他过去的从业经历。通过将技术与这位领导的关注点相结合，例如产品出身的领导比较关注产品，那么你可以从技术为产品发展带来了什么好处说起，吸引他的兴趣，这样你才能够继续不断地深入技术研究。
20. 我的 Leader 生病了，请了长病假，CTO 直接管团队，但是几个月都不开团队会议，我们很迷茫！ 我曾经参加过一次技术管理者培训。培训课上看了一段小短片，讲述的是一位盲人报名参加一次野外马拉松赛。短片中这位盲人有一位导师，这位导师用绳子将自己的手臂和盲人的手臂绑住，比赛开始后两人同时出发，比赛过程中他不断地提醒盲人需要注意什么，例如前面是平路，我们用怎样的步履跑步，前面有个坑，我喊一二三就跳过去，等等。
一路上，盲人始终遵从着导师的指导，顺利完成了马拉松赛。我们作为技术管理者，对于员工的指导，也和这个短片中的导师与盲人的角色类似，需要给予指导，而不是仅仅下发工作安排，或是插着手站在边上看着他们陷入困境。
回到这个问题，我的认知是，无论你是 CTO，还是 CEO，甚至是 UFO，既然你承担了团队负责人的实际工作，那么你就应该每天召开例会，就应该不断地抽时间和大家一起讨论架构、业务流程、技术难点、技术方向，这是你的职责，不要来谈你有多忙，你的职务有多高，如果真的很忙，你可以任命临时团队管理者替你承担责任，而不是让团队处于流浪状态。简而言之，这位 CTO，你失职了，不管你喜不喜欢，既然你直接管理团队，就要以身作则。
作者介绍
周明耀，2004 年毕业于浙江大学，工学硕士，国外投资银行 12 年工作经验，4 年分布式系统，物联网工作经验，10 年技术团队管理经验。IBM 开发者论坛专家作者，Infoq 专栏作者。著有《大话 java 性能优化》，即将出版著作《深入理解 JVM 和 G1 GC》，已提交分布式计算领域发明专利超过 15 项。微信号 michael_tec。
今日荐文
点击下方图片即可阅读
