简介
“管理”作为一项综合能力，是你未来的职业发展所不可回避的，至少你都需要和管理者合作。只不过因为你的角色不同，需要掌握的程度不同。你所有的职业发展，都会围绕着技术和管理这两条腿在走路，一条腿是走不远的。只要是在职场中，就有一个基本法则在发挥作用，那就是“价值兑现”，即，你能收获多少回馈，取决于你能输出多少价值。这里的回馈不仅是指物质回馈，还包括成长感、成就感、幸福感等精神回馈。做技术不重要，做管理也不重要，把技术和管理当成你职业的两条腿，在职场中输出自己最大的价值，才是最好的，才真正属于你。
要不要做管理
对公司而言，真正有价值的是你为公司解决了多少问题，而不是完成了多少工作，工作本身没有意义，解决问题才有意义。对于你自己而言，真正有价值的不是你获得了多快的晋升，多高的加薪，而是你获得了多少持续高强度训练的机会。而这两者，本质上是统一的。
- 你是否认同管理的价值呢？认为招聘面试、辅导员工、向上汇报、开会沟通、流程梳理、资源协调、进度推动、绩效评估等大部分管理工作，都是琐碎的“杂事”，很难从这些工作中获得价值感和成就感，甚至还对于这些工作挤占了写代码的时间而不满。认为管理的工作不如技术工作有价值，通过技术手段来解决问题才是最酷的事情。即使有很多人都认为你适合做管理，而如果你自己不认为管理是有价值的，你是不会开心地长久做下去的。
-
你是否对管理充满热情，并享受这些工作呢？
- 你是否主动地向自己的上级了解过团队的工作目标呢？
- 你是否主动关心过新同事该怎么培养，以及如何更好地帮助他们成长呢？
- 你是否享受去负责一个大项目的协调和推进？它的成功发布是否会给你带来强烈的成就感呢？
- 你是否思考过什么样的流程和机制可以应对团队工作中的那些疏漏呢？
-
你是否看重在管理方面的成长呢？
- 更大的责任。在互联网领域，管理者带一个团队，更多是意味着要承担更大的期待和责任。基本体会不到行使权力的快感。这是不是如你所期待呢？
- 更立体的视角。码代码是最简单的事情
- 更灵活的思维方式。在各种不确定因素中，却要去追求一个明确的目标，这对于很多新的技术管理者来说，思维方式会受到很大冲击。你想扩展你的思维方式吗？
你能收获什么呢？
- 你到了一个更大的平台上，你的能力和视野将得到大幅度提升。这会给你带来明显的成长感。
- 你不但能力变强了，你还有团队了，你能搞定更大、更复杂的事情，做出更大的成绩。这会带给你更强的成就感。
如果说你前面问我“适不适合”，主要是指“你是否可以很好地胜任”，以及“能否拿到自己想要的回报”。那么，此时你就知道要回答好这两个问题，是需要首先回答另外两问题的，即：这个选择是否更符合“你的初衷”，以及是否更能激发“你投入的意愿”。
PS：如果找不到合适的方向和环境，投入会渐渐没有效率，挫败感会反噬。
丹尼尔·平克在《驱动力 3.0》一书中有说：“服从让我们撑过白天，而投入才能让我们撑过夜晚。”这告诉了我们一个很简单的事实：外驱让我们可以做好本职工作，而内驱才能让我们成就卓越。
乔新亮：技术钻研到什么程度，才可以放心聚焦管理技能呢？当你的技术深度，足以辅导团队做技术选型和决策时，就可以聚焦管理了。促使我转向管理岗位的直接原因，是我意识到：有许多工作价值，只能靠团队的力量实现，个人能力再强大也于事无补。我认为，管理的价值会随着团队规模的扩大而增加，在一般情况下，会超过大部分技术专家的价值。对于管理工作来说，聚焦的终极目标是组织成功，这是个体系性问题。要学会在一定程度上，忘记个人的辛苦和努力，因为那只能代表你的个人成长。
周志明：离开技术、放弃编码的决定，很可能会像你高考之后放下的数学、生物、地理等知识那样，一旦放手，以后就很难有机会再重新捡起来。久而久之，你对代码、技术、产品状态与团队研发状态的理解，就会渐渐和团队成员产生偏差错位，从而丧失在细节上给予指导的能力，丧失在专业问题上提出接地气解决方案的能力，只能在短期内无法验证对错的大战略方向上提意见，在会议、流程及团队管理措施上下功夫，在职业经理人式的宣讲与汇报上寻找存在感。如果是这样，那么你就从团队的导师变成了管理者，最后你跟团队的关系，就会从携手并肩奋斗的伙伴，完全演变成了只能靠公司制度与管理职位的权力来维系的雇佣关系。PS：tag 技术管理
关于技术和管理，个人价值体现在自己能力与领导对你期望的匹配，管理能力是一个深度与公司环境绑定的事。在一个公司管理做的好，去另外一家公司可能完全不是一回事。在应对变化的时候还是得靠自身的技术能力、学习能力、执行能力，还有带人成事的能力。这里不是说管理能力不行，是想表达要学会摒弃那些环境因素与外界因素。你离开上一家公司的时候，去面对新一家公司的时候，能带走的与能带来的只是你个人身上的能力和资源，没有其他。
谈谈技术能力在程序员界有一个悖论持续在困惑着很多技术人：在写代码的人的困惑是一直写代码是不是会丧失竞争力，会不会被后面年轻的更能加班写代码的人汰换。典型代表就是工作 5 年左右的核心技术骨干，此时正处于编码正嗨但也开始着手规划下一个职业发展阶段的时候。
- 到底什么是技术能力？两类日常工作
- 重复琐碎类工作，专门处理其他组技术同学对组内业务的疑惑进行解答，我们称之为 daily 支持。你可以、就事论事，把这个问题回答了结束；也可以解答完这个问题后即整理成文档，把排查步骤写清楚，提升自己和同组人的工作效率；也可以将此排查问题的方法和逻辑固化为小工具给到咨询的同学去用，让他以后可以自助排查解决；将此问题背后根因找到，从业务原理或者产品功能上去找解法，寻求彻底根治。
- 抽象复杂类工作，典型特质就是需要只能感受到现象，很难找到根因，没有明确目标和固定解法，需要自己做方案定策略。比如 在复杂的系统链路中往往会出现联调效率十分低下的问题，每个研发同学都在抱怨各种各样的问题，但就是没法去根治。你可以找到抱怨的同学，问一问具体的问题是什么，然后针对性解决；也可以更加广泛收集问题，然后列出来表格，归类分析并安排负责人跟进解决，最后定期跟踪进度。也可以深入分析表格的中的问题并对问题进行抽象，从架构调优和产品功能的角度去寻找原因，并寻找解决这些问题带来的业务价值，并确定目标拆解路径，最后按照任务推进和跟踪进展；进一步，从更全局角度去思考此目标与年度目标的关系，与组织发展的关系，思考如何扩大此事的效益，思考如何通过这些事的解决锻炼和培养团队同学。
- 技术能力层次模型
新leader常踩的坑儿有哪些？
- 过程导向、被动执行。团队方向感缺失，团队做不出有效的业绩，无法带领一个团队。
- 大包大揽、唯我最强。没有梯队，团队成员积极性受挫，由于得不到团队成员的有效支持，自己又忙又累，做不了更大的业务。
- 单一视角、固化思维
- 习惯性卡住。遇到问题和困难，很容易被卡住，到处都是绕不过去的鸿沟。
- 认知层次低。由于被单一惯性思维所支配，认知层次和考虑问题的维度无法提升。
- 难堪重任。由于创造性地解决问题的能力不足，难以承担具有挑战性的工作。
- 自扫门前雪、固守边界。项目推进不畅，从而影响全局的结果。自我设限，因此个人成长受限。个人影响力无法扩展。
- 患得患失。
可悲的现实，大部分技术领导者可能并不称职大部分技术领导者是不称职的。以下列举的几种错误模式在技术领域随处可见，基本都可以对号入座：
- 闷头干模式。延续独立贡献者的工作方法，所有方案自己做，所有代码自己写。
- 路由器模式。上级任务往下转发，任务结果收集汇报。
- 高压模式。对上过度汇报，对下持续增加，辅以不科学的价值宣导。
- 不决策模式。不对任何需求 say no，或者决策全部下放，并让下属承担决策后果。
- 有业务无工程模式。高度关注短期业务交付，不管工程质量。 如何进行管理呢？探讨一下
- 如果说技术领导者只能做好一件事的话，就是做招聘，挖掘人才。一定要给团队招一个正向的人，即与团队目标一致、文化一致，能力一致。如果团队里某个人的专业素养不能支撑住在团队生存的时候，他必然会进化出一种其他方面的能力帮助自己在团队里生存。比如他可能特别“会汇报”、特别会“写 PPT”、特别会“搞东搞西”的一些事情来帮助他自己生存。
- 那重视人才意味着什么？你每周花几个小时做招聘 / 面试 /1-on-1 沟通？你是否对每次面试都严格要求？会不会因为项目压力降低要求？你能欣赏和你不同的想法和观点吗？你有信心充分地授权，并敢于为此负责吗？
- 如何带团队。带团队肯定要定战略、做规划。
- OKR 应该体现团队为谁服务（for who）； OKR 应该体现聚焦（即取舍），资源有限，集中精力办大事。OKR 应该要尽可能量化（不必 100%），用来校准方向，且量化不应被用来考核绩效。OKR 的承接应该遵循 Single Threaded Leadership 原则。OKR 的负责人没有，或者 OKR 的负责人有一堆，都是错误的。OKR 应该公开，且根据实际情况沟通调整。
- 如何建设工程文化？以下是我的一些做法：要求代码开放，要求 code review，要求 unit test；搭建 CI 看板；技术领导者每天参加 code review绩效考核 / 晋升考核中纳入“技术素养”的要求；定义阶段性技术目标，降低系统复杂度（如：下线服务，架构治理）
- 故障 Review 的重要性。从中可以看到这几个方面的信息：系统架构是否存在问题（例如：存在不合理依赖）；研发流程是否存在问题（例如：代码提交没有单元测试覆盖）；运维应急能力是否存在问题（例如：是否第一时间操作扩容），一方面是在看系统，一方面也是在看人。
- 建设开放透明的文化，一些反例：
- A 同学把自己写的代码设置为 private，他人不知道其工程能力，老板也不在乎，但是他非常会写 PPT 汇报。
- B 同学找 C，D 单独沟通获取了大量的信息后，和老板单独汇报（选取对自己有益的信息），促成了老板做出对自己有利的决策。
- B 同学就某个想法找 C、D 聊完后，包装成自己的观点，和老板单独沟通，给老板造成他能力强的印象。
- X 领导在一年中多次改变团队目标，但是未和团队解释这些变化的原因，导致团队士气低落。
- 晋升季的时候，B 同学被晋升了，但是领导没有向大家清晰的公开晋升标准以及 B 同学何以满足这些标准，导致团队各种猜测。
技术管理的患得患失
通晓多种编程语言的程序员，真香？如果我用一句话来定义程序员的工作，那就是“解决问题”。优秀的程序员不一定要编写出色的代码。他需要使用手上的最佳工具来解决业务问题。
核心原因是把管理摆在了和技术对立的位置，同时由于管理能力还没有强大到可以作为自己的核心竞争力，因此忧虑自己的技术会落后，从而失去生存能力。造成的后果：犹豫反复，无法全力以赴去做好管理，成长缓慢；对技术的看法太狭隘，从而影响技术判断力的提升。所谓的留后路，其实也是不学习，不成长，懒惰的表现，这是一种固定思维，而不是我们鼓励的成长思维！有时候“背水一战”是对管理者的最好的鞭策。
技术能力不等同于编码能力：做技术管理，你并没有放弃技术，而且也不能放弃技术，放弃了技术是做不好技术管理的，你只是在一定程度上，放弃了编码而已。那么，都没时间编码，怎样才能做到不放弃技术呢？
- 首先，把技术提到更高视角来看待。做技术的时候，把技术做好就是最大的目标；而做了管理之后，你会把技术作为一个手段来看待，看它究竟能为目标带来什么。这很像在学习组装电脑，即便已经不需要关心主板、内存、CPU 的内部运行逻辑，但你还是要很清楚它们的功能是什么，接口什么样，以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏，也得清楚在整台电脑中，哪个部件可能会是短板，等等。所以，技术转管理并不意味着不关心技术，只是更关心更大的目标和整体结果了。
- 其次，换一种学习方式来掌握技术。你要深刻地认识到，亲自写代码固然是很好的学习技术的方式，但是作为 leader，你需要快速掌握更多的技术，并且快速判断该如何搭配使用，所以你一定得有更高效的学习方式才行。技术管理人的技术水准的提升和保持，主要看能从周围人的身上汲取到多少信息和知识，而不再只是靠自学。
- 建立你的学习机制。你可以想想在团队内建立什么样的学习机制，可以帮助你借助团队的力量来提升技术判断力，并结合自己的情况来创建。定期做交流和分享。
- 请教专家。在了解某一个领域的情况时，借助你的平台，找你能找到的最厉害的专家高手进行请教，他们之所以成为高手，一般都能给出高屋建瓴、醍醐灌顶的认知。
- 共创。在这个知识型工作者的时代，和自己埋头思考相比，共创成果往往会出乎你想象，特别能增长见识，你可以看看在团队中如何建立共创机制。
如果你把“编码时间减少”叫做放弃技术，那我得告诉你一个残酷的现实，无论你做不做管理，这事都不可避免。现实是，你要么做技术管理，用更高的视角来看待技术；要么你继续做工程师，也要用更高的视角去看待技术。
俗话说：“人穷则反本”，当人们遇到困难和挫折的时候，就想回到老路上去，这是人之常情。只是，你不得不面对的一个现实就是，即便回头去继续做技术，也不再是原来那个听指挥听安排就好、做好执行就 OK 的一线工程师，工作“升维”已不可避免。一方面，每个人的内心都有成长的诉求；另外一方面，公司和团队也需要你承担更复杂、更具挑战性的任务。
从借助自己的技术到借助大家的技术。做技术的时候，了解自己能做什么就好了。但是无论是做管理者还是架构师，你都需要带人做事了，这个时候你就需要熟悉团队里每个人的技术情况，知道谁能胜任做什么事情，适合做什么事，然后借助大家的技术去做事。
在编写代码的时候，要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白，修改起来是否简单、安全。考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。再次是机会成本，这是技术管理者做决策时要意识到的。即，当你把人力、时间花在这件事上，同时就等于放弃了另外一件事，而没有做另外这件事将带来什么样的影响呢？就是你要考虑的机会成本，你可能会因为这个思考而调整技术方案的选择。最后，希望你还能意识到协作成本，即多人协作所增加的时间精力开销。一个方案的协作方越多，需要沟通协调的成本也就越高，可控度越低。
归根结底，从技术实现者到技术应用者的转变，不断提升的是技术的使用能力，而技术实现能力由于投入的时间越来越少，会逐渐减弱。例如古代带兵打仗的将军，需要了解步，骑，弓等不同兵种的特性，判断战场局势，知道何时何地何人发起致命一击，但不一定亲自去拉弓射箭。既然你选择了做更大的事情，就不得不适当放弃一些细节，放弃一些技术实现能力，不断提升你的技术判断力，让团队行走在正确的方向上。
有效执行
如果确定是要拿项目结果，就需要做出确保结果的安排。要想让员工分担我们手头上的工作，要么靠梯队，要么靠机制。所谓靠梯队，就是团队里有胜任度非常好的人，可以帮我们搞定这件事，并且这个人已经是这方面可靠的梯队人才。如果靠梯队有困难，就只能靠机制了。所谓靠机制，就是设计一套方案，来专门应对某个场景出现的问题，这套方案可以指导和“搀扶着”员工做好这类工作。自己开发 ==> 交给员工开发 + 自己沟通检查成本 ==> 降低检查成本。作为管理者，如果你想抽出时间干别的，梯队和机制的建设会把你解放出来。
任务执行检查清单
| 有效执行四要素 | 细则 | 备注 |
|---|---|---|
| 目标不清 | 目标不够明确具体，至少没有具体到执行人员可以执行的程度 下级对目标的理解看似一致，实则有偏差，尤其是对进度、质量和效果的拿捏上 目标发生变化了，没有及时同步给相关的人员 |
每个人对“清晰”的理解会有所不同 |
| 责任不明 | 是否有明确且唯一的总负责人 各负责人对于“负责”的理解常常是不一致的 总负责人无效 |
把上级作为“客户”来看待，并另寻总负责人和这个“客户”来对接需求。 |
| 推进不力 | 过于依赖人的主动性，没有成形的机制 机制虽有，没有人确保执行，或大家不愿意执行 机制虽多，没有抓住关键环节 |
|
| 沟通不畅 | 沟通是否主动，还是总在等待 沟通是否达成一致，并就结论double check，并通报 沟通不足，广播出去了就默认对方收到了 |
多任务并行该如何应对？“重要紧急四象限”耳熟能详了，这个“四象限”对于盘点各项工作的优先级是否好用呢？大家都很清楚“重要紧急的工作要排在最前面”“重要的工作要像大石头一样做长远安排”“紧急的工作要立即着手”“不重要不紧急的工作直接丢弃”等应对策略。可是令大家最困惑的是，到底怎么判断一项工作重要不重要，紧急不紧急呢？这个前置步骤才是最难以判断的。
在实际的工作中，我们经常做的并不是梳理轻重缓急四象限，更常见的情形是，我们要把日常的工作分为两种情况：一种是计划内的，也就是按照我们的规划进行的；另外一种是计划外的，即突发的情况和任务。我们的应对策略其实非常简单：
- 对于“计划内工作”，看收益是否足够大。收益越大就越重要，也就越需要给予相匹配的优先级、资源和关注度；收益相对不大，就放入“To do list”，作为待办任务处理。
- 对于“计划外的工作”，看损失是否足够大。损失够大，就按照紧急任务安排，以止损为核心目的；如果损失可控，就转化为一个可以安排到“计划内”的工作
个人体会：“重要紧急四象限” 很有名但一直用不起来，说明不贴合实际。 我们在学习、提炼套路的时候，也注意识别、避免这类华而不实的”思维框架“。
沟通
上级更倾向于告诉你，他们想要什么；而不会主动告诉你，他们愿意用什么来交换。这不是他们“唯利是图”，也不是他们“只让马拉车不让马吃草”，而是因为评估影响并给出应对方案是你的工作，这是你最清楚且拿手的，而上级判断不出对你既有安排的影响到底多大。所以，很多上级管理者跟我说，他们默认是需要沟通的，而不是默认不沟通，最怕大家最后给他们一些“surprise”。
诚意正心：遇到冲突时，跳出自己的角色来判断是非对错，通过审视初心来做决策，很容易让自己充满力量。当然，这无关管理方法论，更多的是对职场法则的认知和理解，也正是这个最基础的哲学，给予我应对冲突的基本逻辑判断。
你的角色是由上级和公司对你的具体期待决定的，而不是你的头衔。常常有跳槽的管理者问我“技术总监都做哪些事儿”之类的问题，这显然是混淆了头衔和角色。因为即使是同一个头衔，在不同公司所需要承担的角色可能是千差万别的，所以，不要指望按照头衔去筹划自己的工作，就可以满足上级和公司的期待。那么，如何厘清自己的“角色”呢？我的回答是：和你的直接上级去约定（如果你的直接上级对你有充分的管理权限的话）。比如，我每次空降的时候，都会问未来上级一个问题：“长期我们很难约定，仅就我入职后的前三个月或前六个月，你觉得我做好哪三件事，你会对我的工作比较满意？”如果对方都没有想过这个问题，你不难发现，对方聘请你的意图是不清晰的，只是觉得应该有一个技术管理者而已。如此，未来合作关系崩掉的可能性会比较大。
管理沟通常见的五类问题
- 视角问题：沟通仅从自己出发，对管理者的角色和视角认知不够。
- 姿态问题：总是在防卫，随时准备战斗。防卫姿态对于管理者做好工作不会有正向价值，长此以往，就等于关闭了别人提供帮助的大门，任其自生自灭，这显然是个双输的结果。所以，工作中最好还是以做事为主，少考虑一些个人感受。如果就事论事地去沟通问题，反而会赢得更多合作者的尊重。
- 方式问题：先给人贴标签，对人不对事。
- 意识问题：沟通没有形成闭环。不能默认对方一定能收到，而且不能默认对方理解的和你想的是一致的。切忌把事实、判断、感受、责任、原因、方案等统统揉到一起来说了：你讲事实他说原因，你说原因他说感受，你说感受他说逻辑，你说逻辑他说责任，你说责任他说解决方案，你说解决方案他说困难……最终就成了“鸡同鸭讲”，互相的不理解和不认同。
- 初衷问题：只给抱怨不给建议。
方法
管理工作的底层逻辑正在从管控到激发
每一种管理方法或管理手段，都是以一定的人性假设为基础的，你认为人是什么样的人，你就会用什么样的手段来管理他。在现实的管理情境中，管理者要抛开对人性的判断，而是要在”抑恶扬善”、”抑懒激勤”的方面来制定管理措施。
把长线项目里程碑化，把日常工作项目化，让员工走一步有一步的成果，会提升员工的成就感。
员工越来越追求工作背后的价值和意义这件事是不可忽略的。所以，作为管理者你需要有能力为员工梳理清楚这个问题。