系统程序员/架构师往往会在团队里显得格格不入，这是因为他们很多都是“独狼”，他们可能脾气很差，也可能在技术上具有个人主义。和这类人不同，杰出的程序员能够以一种优雅、简洁、易懂的设计来架构大型的复杂系统，这些优秀的系统往往能让所有其他程序员的工作都更加轻松。因此，单个人就能带来巨大的杠杆效应。需要让系统程序员/架构师参与到开发工作中，不要让他们只设计、不编码，应该把他们引导成为杰出程序员。
3.团队组成
杰出的程序员需要一群称职的程序员来配合，依赖他们完成日常的开发工作，实现设计好的系统和产品。和橄榄球类似，一个杰出的橄榄球队中必须要有那些负责阻拦和抢断的队员，而一个杰出的开发团队则主要由称职的程序员组成。这让我想起了电影《冲锋陷阵》的最后一幕，四分卫拿着球向对方阵地冲去，周围一群队友阻拦对手球员，能力弱的以自己的身躯直接和对方一对一硬拼，能力强的干掉一个又一个对手，直到四分卫冲过对方底线。这部电影我看了很多遍，也是我带领团队的精神指导，每次看到这一幕，我都会非常激动。
4.薪酬组成
每个人都是独特的，薪酬是由下面这个复杂的公式决定的：
薪酬=i*工资+j*股票期权+k*福利+l*与谁共事+m*工作地点+n*做了什么+。。。。
每个变量前面都有一个与其关联的系数，系数的值会影响公式的结果。每个人都应该考虑对自己来说哪些因素会比较重要、有多重要，然后在0到1之间为系数取值。
5.进度管理
我有一块小白板，我把它放在自己的面前。每天早上我都要写上今天需要参加的会议、自己要做的事情，此外，每天上午半天时间我会和每一个项目（产品开发、预研、调研等）的团队成员过一遍当前进展。大家坐下来，好好谈谈已经实现的设计或代码，对疑惑、问题进行讨论。因为这种方式可以确保自己不仅仅依赖于状态报告、项目时间表，这种方式也可以让你能够接触到说真话的员工，他们会告诉你哪些地方做得不够好，并且会主动请求团队管理者帮助，而不需要团队管理者来催促他们。最高效的团队管理者往往都是坦率的，也往往对下属有足够的时间，能让员工找到他们并说出自己的想法，他们会认真倾听。
从长远看，一些不紧急但是很重要的事情，如果迫于压力被放下，到后面往往需要花费好几倍的代价才能弥补回来，技术管理者需要时刻保持警惕，慎重地做出决策，做正确的事情，要能够为公司的长远利益负责。
6.效率管理
影响组织效率的关键因素是人，如果每一个人效率提高10%，组织的效率就会提升很多倍。团队的效率并不是简单的加法关系，而是乘法关系。所以，如果每个人的效率都能够有所提升，对结果的影响是很大的。
回到技术领域，有一种说法，高效的软件工程师，产出是普通的工程师的10倍。苹果的设计团队，只用了20多个人就支撑起苹果几乎所有产品的设计工作，甚至苹果新落成的环形办公大楼也是他们利用业余时间完成的，其效率令人咋舌。
如果组织中每个人都照章办事，不乱插队，整个组织就是高效的。如果每件事情都有唯一的责任主体，出了问题能够快速找到问题根源，组织就会更加高效。如果流程中每个人都对流程的优化贡献出自己的力量，则组织就会更加灵活，更加高效。
那么如何提高效率？
（1）提高效率，最重要的是先确保做正确的事，再把正确的事做对。因此，先明确目标和结果，以及结果对最终客户的价值大小，这是提升效率最重要的事。在这个基础上，我们会发现很多事情根本就不应该做，而不做就是最大的效率提升。减少一件事情，或者在事情中减少一个步骤，就是最大的效率提升。
（2）所谓效率其实就是性能。性能往往受限于系统的资源瓶颈。我们应该看清楚整个系统中的资源瓶颈是什么，是机器厂房、人力、资金预算，还是周转率，围绕它来组建流程，提升效率。
（3）高效与工具化、自动化程度强相关，因为自动化具有规范、一致、高速、闭环反馈等特性，而且不会因为疲劳而下降。因此高效率的组织，一定会大力发展这些能力。
（4）高效的组织，每个人都会主动优化流程，并且持续改进。
7.引导工作
团队管理者的一项重要工作是引导事情走向正确的方向，并确保团队成员之间以及与其他团队之间有正确的沟通方式。需要注意的是，引导的最终目的是为了让事情完成，而不是把关注点放在如何完成上。对于一个团队管理者来说，要想最大化地利用自己的时间和技能，就要引导程序员自己做出正确的决定，而不应该自己就把决定做了。这样做可以帮助下属员工培养技术、积累经验、建立自信，还能获得具体执行决定的员工的认同。
如果你发现自己经常需要讨论非常具体的命令以及如何执行，说明你没能很好地利用你的管理技能，或者没能赋予下属员工足够的权利。作为团队管理者，你必须指出大方向，然后做好充分的检查，以确保员工做出正确的决定并实现。应及早检查员工做出的重要决定，否则当你想中途接手并做出改正时，员工可能已经做了大量无用的工作。这也是为什么我在“进度管理”一栏中强调自己每天进度跟踪的重要性。
记住，优秀的主管要有足够的自制力，不在下属工作时瞎指挥。
8.保护成员
做过项目的团队管理者一般都有这样的经历，团队成员正在专心处理现场问题，然后莫名其妙被人投诉，投诉可能来自市场部门，也可能来自技术支持部门，或者研发部门。也容易出现团队成员每天被大量无用会议烦扰，不去的话就要被投诉，这类情况在大公司司空见惯。
我们要学会保护团队成员，让他们免受组织中的各种问题、争议和“机会”的干扰。在一些稍大的公司内部，官僚主义会通过各种文书工作来忽略或者缓冲每天的各种请求和问题。在小一些的公司里，面对的挑战是各种销售驱动的机会、客户驱动的争议问题，以及管理驱动的想法，你作为团队领导者，可能是他们最后或者唯一的防线。
很多团队管理者的大部分工作内容是处理这些问题，如果让你的下属去处理这些问题，他们最终可能会被淹没在这些繁杂事情的洪流之中，进而极大地降低他们的程序设计效率。通过保护你的员工，可以让他们避免把宝贵的时间浪费在临时事务上，而且也能让他们工作得更愉快，因为某些问题可能会演变成完整的流言，让人担心项目变更，担心收购、重组或裁员，这些流言会大大降低士气。
此外，你应该保护你的员工免受开发之外的同事或者部门的攻击。这些攻击或者抨击往往没有充足的信息或事实根据，有些抨击是出于好心的，有些则是恶意的，甚至可能包括个人攻击。我的建议是对这种情况保持警惕，处理之前先充分了解情况，如果确实存在无根据的情况，事发当时或事后私下沟通，告诉那个进行抨击的人，指出他的行为是不恰当的，让他知道事情的严重性，而不是一味指责自己的员工做得不够好。
有一种情况我想特别说明：公司内部非重要部门组织的会议，尽量不要放在周五的晚上和休息日进行。利用这种休息时间，看起来很有效率，其实是在过度使用研发资源，过度消费员工对公司的满意度。周五晚上和休息日可以打扰研发人员的事情是：
（1）现场问题，必须立即处理（不处理会损害公司未来利益）；
（2）重要客户提出需求，要求立即做出回复（不处理会损害公司当前利益）；
（3）特别重大的突发事件（对你和公司都很重要）。
9.评估和改进绩效
“信任但要核实”，这是里根总统经常引用的一句谚语，也是列宁的口头语。
团队管理者最重要的职责之一是评估员工的工作绩效，并持续改进他们的绩效。每日反馈、季度/年度绩效审查，以及每月或者每季度目标等都是很好的巩固，可以帮助你完成绩效的评估和改进工作。
比较直接的方式是为每一个人设定工作目标并规定完成的时间，接着定期审查这些目标的进度和实现方式。
10.任务责任制
每项任务都必须有且仅有一位负责人，如果有两个负责人，那就没有人负责了。开发经理的职责是确保为每项任务指定负责人，而不是亲自去完成每一项任务（开发经理可以指定其中的某一项工作由自己直接负责）。应当明确每项任务，确保为每项任务指定一个负责人，推进任务。还要定期检查以下三个问题：“是否清楚整体的目标？是否清楚你的任务对实现整体目标有怎样的贡献？对于你所负责的部分，有哪些东西妨碍你达成目标？”我自己的做法是，只有担任责任人的员工，才能在考核中得到良好或优秀的评价（前提是把事情做好，做不好就要承担责任），没有担任责任人的员工，最多只能给予合格评价。
我们实行了任务责任制，这种长期责任，不是我们的管理保守了，而是在内、外合规的条件下，鼓励在集体主义下的个人更好地发挥。我们呼唤英雄，也要宽容英雄的一些过错。英雄要更加自律，因为天降大任于斯人也。
11.裁员
表现差的人给团队拖后腿的方式很多。他们占用了预算的一部分，但是却无法交付有效的成果。其他人如果看到他们差劲的表现，也会失去动力或者失去对你的尊重。表现差的人可能会影响项目的进度，从而对项目中的每个人都产生不利影响。因此无论如何，这种情况必须尽快解决。
通常，终止合同是一个对双方都不错的选择。表现很差的员工都知道自己很差，他们每天上班和睡觉都背负着这个沉重的负担。对大多数人来说，负担会沉重到难以忍受。所以，当你终止合同时，员工通常会感到一种放下包袱的轻松。很多人会选择离开，也有一些人会选择尝试改进，如果选择后一条路，你一定要定期与这个员工会面，审查绩效情况并讨论结果。
12.主动沟通
承担并顺利地完成与员工的主动沟通，这是你的职责，千万不要轻视沟通能力，这一能力对你的晋升起决定性作用。
两个人只有面对面坐下，看着对方交谈，沟通才不会有障碍。如果你有团队成员在外地或者国外，作为团队主管，你应该主动去拜访他们，并且坚持在那里待一段时间，第一次拜访越早越好。
团队越来越大时，信息之间的传递会变得越来越困难，技术管理者要想搞清楚项目执行的进度、团队成员存在哪些诉求和不满，想要打造一个有战斗力的团队，沟通无疑是最重要的。
我们可以通过配置HRBP的方式来加强和团队的沟通，也可以通过要求团队Leader每两周组织一次与小组成员的一对一沟通，并在每个月底的时候召开一次全员例会，内容可以是欢迎新入职的同学、总结本月重要项目的进展以及存在的问题、介绍下个月要做的重点工作等，让大家对工作有一个整体的认识，并清楚知道自己在全局中所发挥的作用。
13.被动沟通
如果一名团队成员在你不太方便的时间来找你聊天，一定要先把手上的工作放下，专心跟他交流，他可能想鼓起勇气告诉你一件大事。聊天的内容可能很简单，比如缺少完成任务所需要的相关资料或者技能，也可能很重大，比如即将离婚、家人病重或者其他对他个人有重大打击的事情，而这些事件对你的工作时间表都有重大影响。如果你的团队成员知道自己受到了最高优先级待遇，那么在事情将变得很糟糕的时候，他们来找你交流的可能性就更大了。
14.文化冲突
美国有这样一句谚语“吱吱响的轮子先上油。”这句话通俗点讲就是：“有问题或者困难要让别人知道，才会帮助你，会哭的孩子有奶吃。”日本有句类似的谚语：“突出来的钉子先挨敲。”这句话通俗点讲就是：“遇到问题就立即喊出来的人，要被教育了。”这两句话反映了美国人和日本人对于困难的理解差异，所以你要让两个不同文化的民族一起共事，很有大困难。
15.负面效应
有时候会遇到这样一些问题雇员，他们能写出高质量的代码，但设计方案却很糟糕，或者他们的行为会对整个团队的效率起到反作用。
遇到这种情况，刚开始时可以安排适合他们的工作，如果一个项目不那么重要，可以安排问题雇员承担他能力较弱的工作，问题凸显后你就可以找他进行一对一沟通了，通过事实来指出他的问题，努力让他提高。
16.会议记录
记住，没有记录的会议，相当于没有开过。每一个重要会议，都需要有完整的会议记录，包括参加人员、讨论议题（逐一写下来）、讨论过程大体描述、每一个议题的最终结论（包含流程图）、遗留问题、下一次会议时间及议题等。
17.人才评测机制
正如没有完全相同的两片树叶一样，世界上也没有心理面貌是完全相同的两个人。人与人之间的心理差异主要表现在智力、个性和行为等方面。比如，有的人思维敏捷，有的人想象力丰富，有的人脾气暴躁，有的人性格温和，有的人做事认真，有的人行事草率，如此等等。正因为人与人之间存在差异性，每个人都是一个独立的个体，人才评测才变得很重要。可以说，人与人的差异性是人才测评存在的前提条件。
独特性不是在个体身上偶然表现出来的暂时特点，而是稳定的个人特点。一个人在出生后，经过长期的社会生活，逐步形成对待生活的态度和个人的行为风格，这种特点一旦形成，就不容易改变。比如说，一个性格外向的人，不仅在工作单位爱与人打交道，在社交场合也会是一个活跃分子，不仅今年这样，明年也会这样。正因为个人特点具有相对性、稳定性，才使人才测评变得很有可能。如果个人特点没有这种稳定性，人才测评就没有意义了。
企业太多由许多不同层次的、不同部门的岗位所组成。由于每一个岗位的工作性质、工作内容、技术难度和责任都不相同，所以对任职者的素质要求也不相同。因此，人与岗位的匹配问题就成为现代人事管理的重大研究主题。想要做到人岗匹配，首先需要对人和岗位有客观的认识和评价。为了了解和评价人，就产生了心理测试、面试、评价中心等人才评价手段；为了了解岗位，就有了工作分析、工作描述等岗位分析和评价技术。因此，认识是可以被测评的。现代人才测评技术是基于通过观察人的少数代表性行为，对贯穿在人的全部行为活动中的心理特征和能力水平作出推论和量化分析的一种科学手段。
结构化面试就是首先根据对职位的分析，确定面试的测评要素，在每一个测评的维度上预先编制好面试题目并制定相应的评分标准，面试过程遵照一种客观的评价程序，对应试人员的表现进行数量化的分析。
情境化测试包括多种形式，主要有文件筐或公文处理测验、无领导小组讨论、角色扮演、根据所给的材料撰写报告、演讲辩论、案例分析等。
以某通信公司为例。该公司员工入职时确定员工的岗位级别，该级别和薪水等待遇关联，每一个级别的工资上下限相差5000左右。级别从1～3级开始，本科、硕士应届生默认为1～3级。技术级别从初级（8级）开始，该级别和薪水的关系为弱关联，级别升迁不一定代表加薪水。新人入职后需要参加考试，对应类别的1～3级考试。考试通过后，上传述职材料，组织部门内的技术专家评审小组进行评审，然后对该人做出整体评价。1～3级不限制每个技术级别的人数，达到要求即可升级。4级及以上人员，需要上传述职材料，根据申请评定级别，组织上级部门内的技术专家成立评审小组，对上传材料进行评审，并安排答辩。
每个岗位级别对技术级别有要求，即技术级别是岗位级别的必要条件。部门内部各级资源主管评定员工是否可以升级岗位级别。岗位级别在部门内是有固定比率的，所以存在一个高技术级别的员工无法担任高级别岗位的可能性，但考虑到人员是流动的，这个现象不太会持续很久。员工在当前项目组表现特别出色，给予直接升级，每个部门有小比例名额，以提高员工在项目中的积极性。可能存在1个部门的14级工资超过另一个部门15级工资的情况，公司每隔2～3年会进行工资调整，避免这种情况长期存在。
18.下放权力
抓大放小，注重结果。
程序员在工作中经常犯的错误是只见树木，不见森林。举个例子，程序员在得到用户需求后立即开始编程，解决用户的实际困难，但由于事先没有进行很好的策划与沟通，客户的需求总是在不断调整，程序员也总是在修改程序以满足客户的需求变化。这样一来，该项目的周期自然就一拖再拖，似乎没有终点。
管理者需要为成果而工作，以结果为导向。一位卓越的管理者不应该在工作一开始就身先士卒地从事具体的工作，更不应该把精力放在研究技术实现的细节上，而是首先问问自己：“客户期望我做出什么样的成果？”然后再对整个项目进行规划。
19.激励员工
亚伯拉罕·马斯洛在20世纪中叶提出了需求层次模型。在1954年首次出版的《动机与人格》（Motivation and Personality）一书中，他将该理论引入了商界。马斯洛认为，人的需求可以按层次划分，从最基本的对食物和居所的需求，到最高的追求自我完善，在低层次需求尚未完全满足之前，更高层次的激励并没有多少用武之地。
直到今天，需求层次理论依然令人信服，在理解人的动机和个人发展的管理培训中经常会引用它。事实上，马斯洛围绕需求层次理论所提出的观点，今天依然在促使我们不断地改善工作环境，鼓励员工充分发展，自我实现。
我收到过一位网友的提问：“在没有奖金、没有加薪区别的情况下如何激励员工？”针对这个问题，想问他们家老板，连基本的激励都不存在，还怎么让员工做出成绩。
一旦生理需求满足后，人们就会寻求更高层次的满足。佛雷德里克·赫茨伯格在1959年出版的《The Motivation to Work》一书中描述了他认为的激励因素包括成就、认可、工作本身、责任、发展，只有当这些都得到实现和满足时，人们才能得到真正的激励，这样来看，这些因素意义重大，它代表着更深层次的成就。所以，我们只有更好地了解员工的工作动机，才能更好地激励他们。
2.3.2 向上管理
向上管理其实是四个管理方向里最难的一点。什么是向上管理呢？向上管理指的是如何有效管理你的老板以及你要汇报的那些人。另外，你还需要弄清楚如何汇报、如何沟通，以及要采取什么样的行动，才能让你的老板认为你是一个高效而成功的员工。
管理你的老板看起来似乎是一件比较奇怪的事情，但实际上成功地管理好你的老板可能比管理好你的团队还重要，至少对你个人而言是这样的。这背后的原因在于，成功并不只在于你做了什么，更需考虑别人如何看待你所做的成果。现实中，外在认知往往比实际行动更重要。
1.了解老板
如何向上管理取决于你是否能够真正理解你的老板，以及其他你可能间接或隐式汇报的人。如果你是向工程副总裁汇报，那么沟通和汇报可能是技术性的，如果你是向首席执行官或者产品副总裁汇报，那么你的汇报可能就要减少技术性，增加信息，也许还要多加一些与产品相关的内容。除此之外，你老板的级别越高，你的报告就越要精简，越要注重大局，细节更少、局面更大、文字更少、项目符号更多。
关键的是，你需要清醒地评估如何高效地与老板进行沟通。即使是你问他们想要什么，也可能会因为沟通不当，传达给他们错误的信息，或者详细程度不恰当，而他们的自我评估可能也会弄错他们真正想要的东西。所以双方应当一致迭代优化沟通，调整需要沟通的度量。有的事情需要更多的信息沟通，而有的则需要更少。
2.准备讨论内容
不要把每一个问题都带到你老板那里寻求解决方案。仔细地挑选你的问题，只拿那些真正重要的问题去寻求你老板的帮助。当然，如果你能独立解决问题，而不需要他的帮助就更好了。另外，你还要避免只把问题带给领导的情况，最好是拿着几套潜在的解决方案和问题一起交给他。即使你没有特别好的解决方案，或者没有找到最好的解决方案，也会让领导觉得你已经做好了自己的功课，过来找他是为了寻求他的建议和忠告，而不是直接把问题抛给他。
3.主动承担
当问题出现时，你也可以尝试主动自荐，帮助他解决问题。
学会给人惊喜与欢乐。了解哪些事情会让你老板时刻关注，并找到办法超水平完成任务，最好是超过他的预期。有时候其实并不是做得越多越好，而是处理较多复杂问题。
你可以非常好地管理团队并完成项目，但如果没有你老板为你护航，你的职业前途必然坎坷。也许看起来不那么明显，但你的薪水、奖金、期权、津贴和机会的多寡，都是由一系列的管理层闭门会议或者你老板自己决定的。
所以一定要主动，做好向上管理，可能会得到更多的职业回报。你损失的只是时间和精力，但能得到的却太多了。
最后，向上管理本身也有直接的回报：当你为更多的交流做出努力时，会潜在加固和上层领导的关系。可能其中一位领导，会成为你的好友，并在你今后的职业生涯中一直支持你。
2.3.3 对外管理
1.与部门内的人合作
部门内合作的直接效果是，能够让你老板的工作更容易，因为你能解决很多部门内部的事务，不再需要他参与解决。内部合作还能加速项目的完成，因为很多问题和争论，在不被过度关注的情况下，能够更加迅速地得以解决。部门内部合作还能将你和你的同级同事紧密地联系在一起，因为这样你们可以直接共享问题和解决方案，相互鼓励。
这一种合作还可以表现为互相帮助、对遇到的问题互相提供超常规的支持、共享资源和培训，并相互守望。当人们把与自己最亲密的同级同事视为首要援手时，他们更愿意互相协助并帮助对方获得成功。如果你待在一个组织中的时间足够长，那么你的一些同级同事很可能会成为你最亲密的朋友。这种关系应当珍重和培养。
2.了解其他部门
你要一直保持欣赏其他部门的贡献，因为他们的贡献不管怎么看都和你的部门一样重要。
当你被聘请或提拔为程序设计经理时，你需要仔细研究组织架构图，找到各个职能部门的主管，想办法让自己逐渐了解他们，或者是各部门中与你同级的经理。请他们吃午饭，或者偶尔停下来与他们聊聊天，提前建立起彼此之间的跨部门纽带关系是很有必要的，以后你真有需要向他们发出请求或寻求帮助的时候会更加容易。
跨部门的纽带关系不仅能帮助你自己，也是促进不同部门团队之间双向协作的重要途径。在跨部门活动中，尽可能成为一个领导者，而不是追随者。你的主动参与将提高你在整个组织中的形象，帮助你在很多看不见的方面取得成功。你在这些活动中花的时间，将会获得大量回报，因为它们可以提高你的工作执行能力。
3.平级的人相处较难，怎么办
这是网友的一个问题。当你遇到你觉得很难相处的人时，你需要告诉自己，保持自己的职业素养，不要轻易被别人激怒，时刻保持一颗平常心，努力把自己的工作做好。
对于平级的人，如果你确实拿他没办法，我的建议是找你们共同的领导反映你的困惑，或是通过你的领导找到他们的领导，由领导层沟通。对于所有的管理类问题，我觉得首先要自我检查，确保不是自身的问题，然后是沟通，保持高效、简单的沟通，这样可以帮助你至少说出自己的困惑，最后是放松自我，不要被不值得的事情或人所烦恼，过好自己的每一天，全力做好自己的工作，不断提升自我价值，抽出时间陪伴家人，这才是你应该做的。
总结
如果对方是产品经理，尝试以产品的语言去解释。如果对方是计算机科班出身，那么简洁地使用计算机术语，直接说理论的名字或者算法的名字就行（如二次握手、NP等）。如果对方是其他专业转行的程序员，不妨试试直接拿着代码来讲。如果对方完全不是一个行业的，就尝试针对他了解的一些问题和知识来举例解释。
2.3.4 自我管理
最难管理的人总是自己。我们每个人都善于否认，我们会忽视坏习惯、差劲的执行力，以及对其他人无法容忍的问题行为。要有效地管理自己，有效地管理自己的时间，毕竟每个人一天只有24小时，真正的工作时间只有12小时左右，首先需要实事求是地评估自己的习惯、实践和行为，然后找出你想要改变的方面，最后实施你的改善计划。
简单来说，个人管理系统就是一个由世界观和方法论组成的整体，构建这个整体的目的是为了实现自我提升，这个整体里包含个人价值观、个人思考模式、做事的流程体系、做判断和决策的方法和一系列的健康生活习惯等。作为一名软件团队管理者，我们需要避免过度管理，做好沟通管理、面对面管理和形象管理。
1.过度管理
切记，造成延迟和混乱的最主要的原因之一就是允许一个上级直接管理过多的下属。我们自己也要注意这一点，不要过度深入管理每一件事情，或者直接管理每一个团队成员。一般来说，你能够覆盖完整的团队成员，最好不要超过10人，多于10人以上，可以采用分小组形式间接管理。
随着控制范围的扩大，管理者与下级的交互次数（以及由此产生的指导实践）呈几何级别增长。这个说法需要考虑到管理者与下级、下级与下级以及管理者与所有下级组合之间的交互，并且假定花在指导上面的时间与交互的次数成正比。例如，你有4个直接下属，在增加第5个直接下属时，完成更多工作的可能性会上升20%，但是交互的次数则可能会从44增加到100，增加了127%。直接管理8个下属可能需要1080次交互，直接管理12个下属可能需要24564次跟进管理。
2.沟通管理
技术的进步增加了很多沟通途径，且已经远远超过了我们的处理能力。如今，电子邮件、短信、博客、微博、微信、社交网络、Skype、RSS订阅以及其他技术，已经渗入我们的生活当中，而这在几年前是不可想象的。我们已经成为泛滥沟通的奴隶，而这些沟通方式似乎降低了我们整体的生活质量。
要想成为一个有效的经理，你必须建立有效机制来控制和管理洪水般的信息。不能让它控制你。
·制定一个切实可行的做法和流程来管理你的工作电子邮件，不能让接二连三的电子邮件分散你的注意力。
·别人打电话或发短信给你时，你不必一定答复或回应。
·在会议上或在其他需要的时刻，不要让电话或短信转移你的注意力。
·委托管理会议议程。
·仔细规划你的时间，以减少需求和信息的洪流。
·建立或协助建立适当的电子邮件礼仪。
3.面对面交流注意事项
智慧是您一生从聆听而非说话中所得的奖赏。
——亚里士多德
关注对方，放下你的手机，停止处理电子邮件或写代码，坐下来，看着说话的人。用眼神交流，仔细聆听对方在说什么（并思考他们呈现的信息）。注意，信息并不局限于他们的话语，还有他们的姿势、身体语言、热情或专注的程度。留意一切信息，通常语言之外的线索反而是最能说明问题的。
谈话时隔着办公桌，或者隔着任何其他东西，都会让人不舒服。
许多人认为管理是自上而下的，具有权威性的，也就是说，管理者处在金字塔的顶端。恰恰相反，建议你把自己放在金字塔的底部，而你的员工在顶端。他们和他们做的工作才是真正重要的。
4.形象管理
“人靠衣装”其实需要好好思考，如果你看起来邋里邋遢，那么你需要采取行动了，要去克服你的老板和其他高级管理层与你交流时因着装而产生的负面看法。
2.4
影响团队因素
2.4.1 不懂技术的技术领导
不懂技术的人如果做了研发团队的领导，很容易出现严重的问题。例如，技术会议他到底需不需要参加。如果领导是一位技术专家，毫无疑问他需要参加，如果不是，他参加或者不参加，都会引起麻烦，所以尽量避免这样的人出任研发团队领导。另外，对于整个研发过程的管理，不懂技术的人很容易完全从产品角度考虑，忽略研发团队面临的困难和风险，忽略技术人员对于技术的憧憬，造成团队超负荷工作、技术团队缺少技术愿景等情况发生。
举个例子，遇到业务方提出的需求完成时间点过于苛刻的情况（其实这是一个压力传导问题，业务方收到了客户的压力，本来可以通过向客户解释来减少研发的压力和风险，但是选择直接施压研发）。这时候，你的这位不懂技术的团队老大可能会说，没关系，我们一开始并不需要一个完美的系统，你先上了再说，我们后面有时间再重构和完善（当然有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的），这样的想法本质上是错误的。
一些人喜欢将缺少需求分析、技术设计环节解释为“这是敏捷开发，和你们的瀑布式不一样”，这是对敏捷开发的误解，敏捷开发是很好的一套开发流程。敏捷开发的实质是为了解决需求快速变化的情况，需要快速响应需求提出方，快速搭建产品原型用于验证实际效果，而不是说有了敏捷就可以忘记软件工程理论，不管三七二十一，先随便写一堆代码再说，这是不合理的。任何软件工程模型，都不会允许在需求完全不明确、描述不清楚的情况下，开始进行技术方案设计，也不会鼓励在方案设计缺失的情况下开始编码，因为这个时候没有人知道究竟如何编码。
团队领导可以不是对口的专业出身，但是他必须对技术有热情，必须有开发经历，需要对技术有敬畏之心。总结为两点：
·基础知识和理论知识非常重要，多多使用已有的且成熟的方案是关键。
·对技术要有一颗严谨和敬畏的心，想清楚了再干，坚持高标准，很多事情都急不来。
2.4.2 薪资管理
对于薪资，我有一个基本的观点：“对工作努力的人，要给予薪资方面的倾斜，即便他是亿万富翁，该多给的奖金一分都不能少，如果他经济有困难，还要更多给予倾斜。对不努力的人，无论多么困难，天平绝对不会向他倾斜。”公平、公正，是做事、做人的基本原则。
公司政策所导致的薪资不公平或不合理现象很常见，团队管理者的工作是让不公平现象在我们的管理下逐渐变得公平，这也是高效团队管理者的能力要素之一。很多时候，员工其实并不在意工资低一些，但是如果他们发现同级别的人工资比他们多很多，这时候就会出现强烈的内心冲突，一般这种情况你需要立即处理，安抚他们，并解释为什么会出现这种情况，并承诺后续如何平衡。
千万不要以为“公司内部不能谈论工资”这一条很有用，这条规定对于有大量同学在一起的大公司来说，几乎不起作用。我们要做的是，在公司开始慢慢有稳定的收入后，逐步调整薪资并向优秀的员工倾斜，让他们的付出得到合理的回报，并在薪资、奖金和期权分配上为他们争取更多的回报，这是对优秀人才最好的奖励。除了薪资以外，我们可以给予他们信任和空间，让他们承担更多职责，即使中间可能会搞砸，也要继续大力支持。其实，在成长的过程中，捅娄子的事情不可避免，但只要勇于面对、积极改进，一般不要在这些事情上过于苛刻。
团队中其实不缺聪明能干的员工，但是限于种种制约，很多人并不知道该朝哪个方向去努力，这时技术管理者应该结合自己对业务、平台、团队等综合情况的了解和影响力，给大家指明一个方向，搭建好一个可以让他们施展的舞台，剩下的就不用太担心了，他们会做得很好。
总的来看，对于薪资，我们应该注意以下几点：
·按照能力和他的付出进行衡量，不要把个人情感混淆其中。
·制定标准化的考核规则，输出能够让人信服的流程和细则。
·薪资的组成结构最好能够多元化，这样可以让员工在每一项奖金中感受自己的付出和回报。
·薪资真的是第一要务，一定要把握标准，做到公平、公正，不然你的团队会垮的。
2.4.3 上升通道
基层程序员在工作几年后，一般有能力的都会被提升到PL、PM、SE等职位，员工也都想着能够被提拔，逐渐成为管理者。大家觉得，光做开发没有职业前途，永远都处在金字塔的底层。而在硅谷的公司，说话比较有分量、收入相对较高的人，他们有很多是在各层级中的技术佼佼者，他们备受尊重，干得也开心，不少人根本不愿意转做管理者。
编程其实是一门艺术，热爱和用心是非常重要的，相应的也容易出成绩。这就是为什么在计算机领域，如果做到顶尖程序员，一个人顶一百个很正常。如果程序员觉得没有前途，不思进取，而资质较好的程序员很快又被提拔为管理者，那我们的软件开发将很难有技术和人才的积累。
不要期望每个人都以同样的方式来进行管理。每个人在工作与管理时都有自己的风格与方法。重要的是关注结果，而不是方法。有一些事情你必须坚持，但这些往往都是基本的领导质量问题，而不是具体的管理方法问题。
我们作为技术团队管理者，应该多与每一位下属沟通，抽出时间来了解他们对于未来的期望，帮助他们逐渐设计符合他们想法的上升通道。当然，你给予他们机会，最终需要他们能够承担这个机会，承担机会意味着付出，如果这个人不愿意付出，只是口头不断表达自己的想法，那么所有的上升通道都不会向他敞开。
2.4.4 大规模变革
“没有什么比建立新秩序更困难、更无望成功、更危险的了。因为旧秩序的受益者都是改革者的反对者，只有那些可能从新秩序受益的人才会勉强支持改革。”
——Niccolo Machiavelli
你一定要慎重执行大规模变革，无论是组织架构，还是人员任命，因为所有的改变，都会在人的内心引起权力欲望和恐惧。多做核心人物的思想沟通工作，不要由闭门小团体会议决定所有的改变方案，这样会让核心技术人员感觉到被边缘化、被决定命运。记住，只有多沟通才会让核心人员内心存在被尊重的感觉，而不是仅仅给他们加工资，人是有感情的，让他们感觉被尊重，胜过加薪。
2.4.5 一言堂
技术团队如果出现喜欢搞一言堂的领导，逐渐会形成他的个人特权，刚开始不会让人感觉恶心，但是逐渐地他会越来越肆无忌惮，直到团队中有个性的、有能力的人全部离开，只剩下一些实在走不掉的、很能忍的，那么这个团队的整体战斗力就变得很弱。
总的来说，还需要针对团队管理者制定多方面考核机制，要有自下向上的反馈渠道，避免出现有违公司政策、违反劳动法的事情出现。
作为一名团队管理者，有一点是需要做到：“不要作恶！”
2.4.6 频繁开会
根据Business Insider报道，美国员工每天总计需要参加1100万场会议，无效会议每年消耗美国公司370亿美元。苹果创始人乔布斯认为，会议规模越小越好，为此，他还曾拒绝过奥巴马邀请的一个科技大腕会议，原因是邀请名单太长了。乔布斯主持会议的风格就和苹果产品一样简单明了。他厌恶开大会，因为一个房间里有太多人的话就会争执不休。有一次，会议开始时他发现房间里出现了一个以往没有出席过会议的人（一位自称正在做市场营销项目需要参加此次会议的女士）。乔布斯询问对方是谁，最后礼貌地请她出去：“我觉得我们不需要你在这个会议中。谢谢。”那位女士只好收拾好自己的东西离开了。
Alphabet（谷歌的全新母公司）CEO佩奇曾经向全公司员工发送了一封题为“如何高效开会”的电子邮件，邮件中的一条要点是：“每个会议都必须有一个决策者。如果没有决策者或者会议中无法产生决策，这个会就不应该开。”
我的一位同事，原先做人工智能算法，后来升为经理后，最多的时候一天参加8个会议，平均也有4个会议，你说他还能安心搞技术吗！现实工作中，由于组织复杂，中间层较多，各种各样的任务从上面下来，落实的方法就是各种各样的会议，所以现在很多研发员工的不少时间都被各种各样的规划、研讨、问题回溯、客户支持等会议占用。员工笑称：“白天是用来开会的，晚上加班才有时间编程序。”针对于不同的组织和项目，能尽快找出相应的沟通节点并能有效地减少这些沟通节点，是一个项目和部门领导需要经常思考的问题。
如果你喜欢有条理的议程，那么就让员工设定会议议程。最好能让员工提前向你报备议程。这样做，如果没有紧急的事，员工就有机会取消会议，也能让员工知道这是他的会议，占用的时间完全取决于他。因为是员工的会议，经理的发言应该只占10%的时间，剩下的90%都是倾听。
2.4.7 各种无端限制
如果你懂开发编程，一定知道什么是“锁”，锁就是用来同步和互斥。我发现很多开发部门里的各个开发团队间存在很多锁。比如：
·技术能力上的锁。有一个项目需要在不同的地方做开发，这些模块用到不同的技术，比如Java、C/C++、Python等，但是这个团队里的每一个开发人员只懂一门语言，于是，需要配合，需要任务排期，同步互斥锁就很多。于是，一个本来只需要两个人干三周的工作变成了八个人干两个月。
·负责模块上的锁。同理，不同的人负责不同的模块，于是一个项目需要集成好多模块，那么你就需要把这些模块的人找过来。和上面一样，每个人都有自己的时间安排，人越多，锁越多。于是，一个本来只需要两个人干两周的事，变成了八个人干一个多月。
·时间锁、进度锁。有不同技能或是负责不同模块的开发人员有锁，有锁你就要等，他们有自己的安排，所以，要协作起来，你就需要排期，去同步。而参与的人越多，你的锁就越多，你协调的时间就会更长。
·沟通锁、利益锁。最恐怖的事情是，他们之间的沟通成本巨大。他们会花大量的时间来讨论一个功能是实现在你那边，还是他这边。每个人都有自己的利益和算盘，无形中增加了很多推诿、官僚和政治上的东西。
