简介

来自对极客时间《技术领导力300讲》洪强宁的文章的整理

深度还是广度

理论上先深度后广度，是一条自然的路径。毕竟有太多泛而不精的半瓶水。

程序员是要专精，还是要广度？

1. 对于绝大多数人来说，编程更多的是职业发展道路上一个立身的手艺，在众多专业技术方向上挑了一个自己比较喜欢和热爱的。程序员的发展和众多职位的发展一样，每个人都希望自己能够往”上”走：更专业，更能在职场上发挥自己的作用和影响力，从单兵作战做小事，到带队做大一点的事，再到影响一个领域，影响一个行业。这样的发展单单靠自己各方面都懂，都有涉猎，恐怕是不行的。刚毕业的应届同学可以靠自己的知识储备做自己的标签，久经职场的同学必须靠自己在某些领域做出的成绩做自己的军功章。所以我们越早在某些方向做出自己的成绩，对自己的成长和发展是越好的。每个人也确实需要一个认识自己的过程，但这个过程我想还是越快越好。在这个过程中，我们自己的技术发展就像是一棵树，我们尽可以无限的去展开自己的枝叶，多了解一些不同的方向和知识，但一定记住这是为了让自己的枝头长得更高。
2. 做一件事是要精还是要广？其实相当于赌博里你是要多压，还是要单押。我们的筹码是有限的，当然我们的精力也是有限的，不可能去做所有的选择。那么这时候，问题就变成了如何去组合投资获得最大化的收益。PS：精力投资

广度的必要性

1. 某些职位就要求足够的广度
2. 有的人（比如笔者）兴趣比较发散，不太喜欢只深挖一个
3. 多角度决策，比如学习linux的源码，单单学习java不一定会学linux，单单学习docker也不一定会，但既会java又会docker 的人会有最强烈的冲动去学习linux
4. 高层次审视问题， 比如研发效率提高的问题（笔者研究过一段的持续交付系统），做好之后，虽然公司层面的管不了，但可以先把组内的研发效率提高一下。
5. 做深的人自然有广度，做广了的人，加上一定的主动意识，也会有深度。只有做深了，才能接触到一些偏本质层面的东西，再加上一定的宽度，你会发现本质层面的东西都是一样的。进而有自信忘掉不必要的细节，脑子里不仅要有货，而且扔掉零碎，只保留有价值的干货。脑子里知识多而琐碎，就不能给干货腾地方，干货少，就妨碍你拓展自己的能力边界。
6. 很多抱怨来自于自己的工作范畴之外，不要去抱怨这个问题，解决这个问题。
7. 广度的重点不在广，在消化，在心得体会，在触类旁通，在完善已有的知识体系， 你得确保你对知识的提炼有一定的深度，以至于你根本就不担心忘了细节。触类旁通了之后，碰到一个新东西，应用已知的知识，了解之前没见过的问题，广就是深。
8. 问题解决的多种方式，比如一个零件，可以机床切削，也可以3d打印。

关于学习知识的深度和广度的思考 但实际上因为个人的喜好、岗位的流转、机遇的把握、环境的变化、技术的更替、甚至家庭因素，都会影响一个人对知识的积累。

1. 吸收效率:当一个知识学到一定程度，会越来越难，花相同的时间，很难再达到相同的效果。这个时候，完全可以拓展广度，说不定触类旁通，一个灵感就能让你在原来的深度上一下领悟。死磕难点往往不起作用。
2. 急用的知识优先学
3. 价值突破:人有涯而学无涯，知识永远学不完，但人需要利用知识走好每一个阶段，让自己不断升值。所以从这个角度来说，深度、广度都不是最重要的，而你的价值突破是最重要的。怎么解释？就是说你越容易从哪个方向做出价值，得到认可，就去从哪个方向突破，不要为了学而学。
4. 快速学习的能力:在用人单位或者公司里面，解决问题是根本。深度不是靠系统学习出来的，而是解决实际问题，不断加深经验和认知出来的。
5. 多一个选择多一个机遇，大部分人总认为自己适合做什么，于是往往会按照自己既定的规划去奋斗。但一个人的价值和潜力，往往不是自己能事先决定的，而是外界的场景和机遇发现的。比如区块链，就是结合了金融与计算机的相关知识。

作者的思维方式运用了

1. 一切从实际出发，看重可行性
2. 从“深度”方式 实际的困难入手分析

所以从整体看，要破除 广度和深度 的执念

1. 都有优缺点，要看几天工作环境和兴趣
2. 广度和深度 不是学习知识的区分方式，还不如说要基础知识深度学，应用型业务型知识宽泛学
3. 一个重点的是需要
4. 一个维度是时间，足够的时间、足够的积淀 在广度和深度上都有一定突破。

《大厂晋升指南》P5/P6的核心关键词是完成任务，P7/P8的核心关键词是达成目标，它们的差别在于：任务是从过程角度来衡量的，而目标是从结果的角度来衡量的。P8 提升技术能力的关键是深度和广度齐头并进。PS：所以广度和深度的侧重不是一成不变的。

左耳朵耗子：

1. 把你看到和学习到的信息，归整好，排列好，关联好，总之把信息碎片给结构化掉，然后在结构化的信息中，找到规律，找到相通之处，找到共同之处，进行简化、归纳和总结，最终形成一种套路，一种模式，一种通用方法。
2. 坚持也不是要苦苦地坚持，有循环有成就感的坚持才是真正可以持续的。所以，一方面你要把你的坚持形成成果晒出来，让别人来给你点赞，另一方面，你还要把坚持变成一种习惯，就像吃饭喝水一样，你感觉不到太多的成本付出。只有做到这两点，你才能够真正坚持。
3. 把你新学的知识点关联到已知的事物上来。比如，你在学习 Go 语言，你就把一些知识关联到自己已经学过的语言上比如 C 和 Java。通过类比，你会学得更扎实，也会思考得更多。

周志明：像计算机体系结构、编译原理、操作系统等原理性的知识，对于不写编译器、不开发操作系统的程序员来说，在实践中是几乎找不到直接的应用场景的。可是毫无疑问，这些知识就是程序员知识体系的基石，是许多实用技能和常见工具溯源的归宿。我们花费一定的成本去学习这类知识，目的是要把自己的知识点筑成体系，把大量的、不同的、零散的知识点，通过内化、存储、整理、归档、输出等方式组合起来，以点成线、以线成面，最终形成系统的、有序的、清晰的脉络结构，这就是知识体系。程序员是需要终身学习的群体，当有新的信息输入时，如果能在知识体系中快速找到它应该安放的位置（place it in context），定位它的问题与解题空间，找到它与其他知识点的关联关系，那你接受新信息的认知负荷就降低了。通俗地讲，你就有了比别人更高的学习效率，更敏锐的技术触觉。如果一项知识或技能，你学习起来非常吃力，花费大力气弄懂之后，过一段时间却又迅速地忘掉了，这很可能是因为你既没有实际应用它的场景，也没有在知识体系中建立好掌握它的稳固的前置基础。这种就属于你目前还拿不动的东西，不如趁早放手。你也不必觉得可惜，如果它对你来说是必要的，就一定还会再次出现，想躲也躲不掉。 李智慧：如果这些知识点对于你而言都是孤立的，新知识真的就是新的知识，你无法触类旁通，无法利用过往的知识体系去快速理解这些新知识，进而掌握这些新知识。你不但学得累，就算学完了，忘得也快。所以不要纠结在仅仅学习一些新的技术和知识点上了，构建起你的知识和思维体系，不管任何新技术出现，都能够快速容纳到你的知识和思维体系里面。这样你非但不会惧怕新技术、新知识，反而会更加渴望，因为你需要这些新知识让你的知识和思维体系更加完善。 于航：构建知识体系的方法：

1. 熟读经典，来完成你对某个领域知识的“原始资本积累”；
2. 在第一步的基础之上，再去广泛涉猎更多相关书籍，并进一步查缺补漏，加深理解。

对于某一个特定的知识领域，当你阅读的相关书籍越来越多时，你能从每一本书中获得的新知识可能会越来越少，因此，你阅读整本书所花费的时间也会越来越短。而在阅读“新书”的过程中，里面涉及到的“旧知识”又会刺激你大脑中先前已经构建好的，与这块知识相关的神经元，从而让你对这部分知识的记忆变得更加牢固。随着你掌握的知识越来越多，新知识逐渐变为旧知识，而旧知识又不断变得更加深刻，你对新书的“消化”速度也会越来越快。长此以往，便会形成我们常说的“飞轮效应”。

系统化的知识体系与碎片化的内容摄取，并不冲突。构建知识体系，确实需要大段的、集中的时间，但是一旦建立，体系内的一个个知识点，完全可以利用碎片化的 20-30 分钟来搞定——番茄时间以 25 分钟为单位还是有科学依据的。

广度与深度的切换

阿里毕玄：技术人应如何选择职业发展路线？作为技术人员

1. 在刚起步阶段时，首先需要拓宽自己的技术宽度，对自己所做的项目/产品所涉及的方方面面的技术都应该有所了解，另外对于就是学习工程化，让自己真正具备开发商业软件的能力。
2. 在工程化和知识宽度达到一定阶段后，需要开始根据自己的兴趣和工作内容有所选择，主要是加强在某一领域的技术深度。
3. 在技术深度达到了一定阶段后，需要对自己做出一个选择，就是偏业务方向，还是偏基础技术方向。

许式伟：毕业两年成为首席架构师，我的技术学习方法论

1. 学技术不能过于专精，需要横向理解，向广度挖掘。
2. 任何一件事情，想做到极致，就要当成学科去研究。如果仅仅当成一个简单的任务完成，能取得的成果会很有限。
3. 光有技术远远不够，必须理解业务及其运作方式，思考产品和商业的关系。
4. 选择和信息的对称程度有关，你越不了解一个东西，越会趋向选择保守性的方案，当你对某个领域了解得足够透彻，决策过程会非常自然。

技术的广度非常依赖于积累。你一定要带着问题去想，这个时候你才有记忆力，有了积累，慢慢的你技术的广度就会越来越深。

刘慧卿：到底是要做一个专才，还是成为一个全才？这个问题还要以发展的眼光来看。现实中往往是“T型人才”比较受用，由于行业的快速迭代，叠加各种不确定性，有些岗位的合理性受到不同程度的挑战，失去竞争力，遭遇下岗的境遇。于是业内又喊出了“π型人才”的概念。梳子型人才更加形象了，多条腿走路，即在多个专业有深入的专业知识，同时在顶层保持一个终身学习的习惯。它代表着强大的底层思维和逻辑能力，它决定了你是否具有知识迁移能力，一定要先夯实它，否则很容易变成三天打鱼两天晒网。人的精力和能力是有限的，机会也不是人人都能碰上的，所以梳子型人才往往不是第一目标。可以先从T型人才开始努力，时机成熟之后再往π型，甚至梳子型人才上迈进。

闵大为：有一句话说的好：“打过仗，打过胜仗，打过硬仗，打胜过硬仗”。我们要先经历多次失败，直到遇到成功，然后体会，在尝试中坚持，然后运用推动成功。日常做事也类似，我们应该从“宽的知识”出发，多了解；然后发现好的，进行“深的理解”；然后再补充“宽的知识”，发现机会，再进行尝试，进行进一步“深的理解”，不停反复。除了认识到这两个是同步进行之外，单独比较的话，我很难说“广度”和“深度”哪个更重要，因为不同的阶段真的不一样：

1. 适应阶段：如果刚入职的时候，我认为广度更重要，短时间内要把完成研发任务所需的知识都灌一遍，需要快速具备技能，才能活下去，才有机会获得更好的任务。
2. 发展阶段：如果往后发展，我认为深度更重要，因为这是你立足的根本。如果没有一个深入的事情，很难形成完整的方法论，也就无法对日常的事情进行快速吸收、转化。
3. 引领阶段：熟练地交叉使用，在缺少知识的时候，能够具备广度，了解行业趋势；在具体执行的时候，又要深入进去，具备深度，能够基于理解合理取舍。

李云：我觉得任何一个人都可以思考下，你的核心竞争力是什么。核心竞争力就是我们的长处，如果我们很难说出来自己擅长哪方面，那这就是有问题的。前几年大家常说要做T型人才，一横一竖。我见到的很多人，他们都是只有那一横，在公司里，什么都可以做，但什么都不精，这很难构成核心竞争力。核心竞争力更多是先竖再横。我们必须在职场中构建自己擅长长的领域，擅长的事情，并且随着时间的推移，你会发现，因为这事你研究得足够深，所以能力也就容易迁移。先报一个学深了，再学其他的，就会容易很多。除了设立目标，我整体的学习方法是深度优先。深度优先能帮助动我建立信心，一旦有了信心，再去拓宽知识面，就不会觉得有问题。当然,我这么说可能有点理想化，实际上在工作中，深度和广度是交替进行的。

程序员能力有哪些

在分析问题怎么解决之前，有时候要先说清楚问题是什么。

不管是深度还是广度，程序猿的能力有哪些？ 阿里P10毕玄：Java大牛程序员的学习成长路线

1. 技术能力成长 【方法论】从入门到精通是怎样一种体验 ，现实世界的知识点是分型网状结构，随着你的经验越来越丰富，你会发现知识点越来越多，越来越乱，自己记忆力跟不上了怎么办？这时需要系统的梳理知识点，将修行从外功转向内功。化有为无。在计算机数据结构中，一个网若能简化成树（最小生成树），就能高效地增加、删除、修改、查找任意节点。将知识点梳理成为树，以后遇到问题时就能迅速定位原因，触类旁通，快速应对。而且一旦有新的知识点进入，能很快地分类到合适的地方，加快下次访问速度。其实也只有你自己知道，根本无所谓精通不精通，而是你知道自己该花时间在哪些方面，不该花时间在哪些方面。把树状结构化为线性链表。设定一个个目标，步步为营，攻城略地。从入门到精通这条路，你越走越顺了。

2. 架构能力成长

   1. 只做自己专业系统的架构师 ==> 跨专业的系统的架构师。
   2. 最重要的职责是怎么控制项目的风险，或者说作为架构师，你觉得一个项目中最重要的要掌控住的是，并且从架构上怎么设计这个部分。要根据实际的项目/产品情况来突出重点，确保最重要的几个问题是从架构设计上就去掌控的
3. 技术leader 修炼。首先要心中有数：在什么场景下，可以通过什么样的技术来解决问题，解决到什么程度。

赚多少钱，很大程度上取决于你的“不可替代性”丨21读书天赋的误区

1. 天赋不是你做得最好的那个事儿，是你学1个小时，等于别人学10个小时的那件事儿
2. 除了能力天赋，还有一个更重要的，叫做意愿天赋。判断一件事儿，你有没有意愿天赋，问自己这么几个问题：是不是一上来就特别有信心，是不是本能上就兴奋，是不是很容易专注进去，是不是做好了特别有满足感。
3. 认知格局。认知容易，但你的认知“力度”是否可以支撑你投入真金白银去做，就是另外一个问题了。
4. 这件事儿，和我的未来有什么关系？

我只想做技术，走技术路线软件工程师，不是搞学术，而是搞工程，而工程能力，是一个非常复杂的多面体。除了 “硬技术”，必备的 “软能力” 有很多

1. 换言之，“沟通” 也好，“管理” 也罢，即便对于技术人来说，也都是逃不掉的。你要跨团队合作，你要带着一票人一起攻克项目，团队能达成的事情，在重要性上往往要盖过自己在努力啃着的特定的问题。
2. 对于实际问题、模糊问题的挖掘和剖析能力。实际问题总是模糊的，先要把问题搞清楚，抽象成一个软件可解的问题，再使用各种软件的工具（代码）来解决问题。而在我们所熟悉的教育体系中，后者被极大地强化——算法、数据结构、库、平台……这些涉及的技能领域，都在后者这个 “解决一个已经经过抽象了的问题” 上面；而对于前一步骤的学习，往往是不足的。什么才是 “模糊的实际问题”？随便举个例子：我们公司内部有大约 100 个服务（service），提供不同的功能，分别由不同团队维护。现在需要你带领一个小团队，来设计实现一套监控系统，统一监控管理这些服务的健康状况。你打算怎么做？这就是一个非常模糊的实际问题，不是一个算法问题，也不是一个传统意义上的系统设计问题。但这是一个真正的、实际的 “软件问题”。

成长方式

暨家愉

1. 本能型成长，可以理解为源于自己的意识、兴趣和愿望，或是你想要改变现状，渴望得到进步。本能型成长是最有效率的，过程也是最快乐的
2. 应激型成长的理解是，我们身处在某个环境中，由于外部因素的变化，导致自身不得不进行成长，以适应这些变化。由于不是自愿发生的，应激型成长往往是一个痛苦的过程。

本能型成长由于受本性驱动，往往能够给我们带来更好的体验，而应激型成长则较为痛苦。那么是不是说，我们应更多地依靠本能型成长，促进自己进步达到最大值呢？尴尬的是，这不是一个选择题。外部世界的变化会要求我们必须作出相应的改变予以回应。我们可以给予回应的时间有时候并不由我们自己决定，假如没有在限定的时间完成应激和成长，那么面临的就是无情的失败，甚至是淘汰。

该怎么打破舒适区呢？在这里，我故意使用“打破”这个词，而不是“走出”，怎么理解呢？对于原舒适区的打破，最终会融合原来的舒适区，给我们一个更大的舒适区。而这些舒适区里面的知识，也会慢慢演化成我们军火库里面不同的武器，给我们以后再次打破舒适区提供支持。

滴滴曹乐：如何成为技术大牛？

1. 刻意练习包含了三个步骤。第一，找到你要学习的这个领域体系的范式（pattern）；第二，针对每个范式刻意的反复学习和练习；第三，及时反馈。正确的学习方法是把打羽毛球拆解成步法和手上动作，小碎步，米字步，正反手挑球，放网，正手和头顶高远球吊球杀球等（寻找pattern），然后针对每一个动作反复练习（刻意练习），然后请教练或者录下来看视频纠正自己的动作（及时反馈）；而错误的学习方法是，上来就盲目找人打比赛，以赛代练，这样的进步是很慢的，而且错误的动作形成习惯以后未来反而很难纠正。
2. 工作本身就如此繁忙了，哪里能抽出足够多的时间去学习？工作本来就应该是学习的一部分，是学习中的实践和及时反馈的部分。这里一个常见的误区是，学习的内容和工作的领域没有太多直接的关系。我以前曾经花了非常大的功夫去读Linux内核的源代码以及很多相关的大部头，几乎花掉了我将近两年的所有空闲时间，然而在我这些年的工作里，几乎是没有用处的，最多就是有一些“启发”，ROI实在是太低了，现在也忘得差不多了。如果把学习分成从书本中学，和从工作中学这两种的话，那毫无疑问，工作中的“知识密度”，比起书本的“知识密度”，肯定是要低很多的，因为书本里的知识，那都是人家从他们的工作中抽象总结出来的。这也是为什么大家普遍觉得日常工作“琐碎”。然而工作中每个点滴的琐事与平凡，都是可以抽象总结成为方法论的，更别说工作所在的领域自身的博大精深了。从日常工作中学习的秘诀，就是“行动中思考”。
3. 对于每一个软件工程师，最重要的两个能力，是写代码的能力和trouble shooting的能力。
   1. 提高写代码的能力的核心，首先在于坚持不断的写，但更重要的，在于每天，每周，持续不断的review自己之前的代码；同时，多review牛人写的代码。一旦觉得自己之前的代码不够好，就立刻复盘，立刻重构。更重要的是，多思考自己代码和好的代码之间不同之处背后的为什么，通常这就是为什么这些代码更好的背后的秘密。
   2. 要提高trouble shooting的能力，关键在于要深度复盘自己遇到的每一个问题，包括线上的，包括测试发现的，寻找每一个问题，每一次事故背后的root cause，并且思考后续如何避免同类问题，如何更快的发现同类问题。要对团队内外遇到的所有问题都要保持好奇心。PS：解决问题的心态是好的，但消除问题则更好。
   3. 构建相对完整的当前技术领域的知识体系。一方面是在日常工作中，对每一个接口设计，每一个逻辑，每一个模块、子系统的拆分和组织方式，每一个需求的技术方案，每一个系统的顶层设计，都要反复思考和推敲，不断地复盘。另一方面，需要大量广泛地学习行业内相似系统的架构设计，这其实就是开天眼。除了技术领域本身外，架构师需要非常了解业务上是如何使用我们的系统的，否则非常容易over design，陷入技术的自嗨中
4. 很多时候技术上绕不过去的坎，可能非常复杂的实现，往往只需要上层业务稍微变通一下，就完全可以绕过去。对于一个需求，如果他给出了好几个可行的方案，说这些方案也可以，那些方案也可以，往往说明他在架构师的路上还没有完全入门。架构师的难点不在于给出方案，而在于找到唯一的那一个最简单优雅的方案。

总结起来看，行动中思考，就是始终保持好奇，不断从工作中发现问题，不断带着问题回到工作中去；不断思考，不断在工作中验证思考；不断从工作中总结抽象，不断对工作进行复盘，持续不断把工作内容和全领域的知识交叉验证，反复实践的过程。在工作所在的技术和业务领域中刻意练习，加上行动中思考，就是成为技术大牛的秘诀。其实在成为技术大牛的路上，方法反而是没那么重要的。真正困难的，在于数年，数十年如一日的坚持。太多人遇到挫折，遇到瓶颈，就觉得手头的事情太乏味枯燥，就想要换一个方向，换一个领域，去学新的技术，新的东西。而真正能够成为大牛的，必须是能够青灯古佛，熬得住突破瓶颈前长时间的寂寞的，必须是肯下笨功夫的聪明人。因此，和坚持相比，方法其实并没有那么重要。

蔡超：坚持编码。架构师也是程序员，代码是软件的最终实现形态，停止编程会逐渐让你忘记作为程序员的感受，更重要的是忘记其中的“痛”，从而容易产生一些不切实际的设计。大家可能听说过在 Amazon，高级副总裁级别的 Distinguish Engineer（如：James Gosling，Java 之父），他们每年的编码量也非常大，常在 10 万行以上。

(学习力+思考力) x 行动力，技术人成长的飞轮效应总结如果抽象成长和发展的三个关键词，我会抽取『学习力』和『思考力』以及『行动力』，三者之间是一个飞轮模型，学习和思考相辅相成、互为关联、相互促进。学习和思考的关系，学而不思则罔，思而不学则殆；行动力在学习和思考的基础上引入，反哺学习和思考，思考、学习和行动力是乘法关系，使用得当，可以很好地产生化学反应，飞轮模型可以持续运转。PS：之后文章细讲了如何学习？如何思考？如何高效行动。

管理

研发管理

聊一聊在阿里做了 8 年研发后，我对打造大型工程研发团队的再思考很多项目在做架构设计、代码设计的时候，是没有考虑后续小步快跑的，不能小步快跑地添加新功能、解决新需求的话，就会经常性导致部分需求做了一半要延期的时候，根本停不下来，这个版本根本无法临时放弃需求而继续发版；更严重的是，需求和需求之间还是强耦合的，一个需求做不完，其他需求也不能正常发版。这都是实实在在的技术问题、代码问题，而不是管理问题。

很多研发主管都喜欢有事没事在钉钉、微信里询问一下具体的工作进度，或者拉个会议对一下进度，所以 “已读 + ding 一下“ 对他们来说是一个很好的功能。我们非常不鼓励这种依赖即时通信工具或会议的方式来沟通、了解开发进度，这种方式非常同步，就和同步调用一样。正确的做法，应该是开发同学每天根据自己的情况及时在项目管理工具对自己的任务进行进度更新和总结反馈，研发主管自己按需关注任务的研发进度和情况，彼此没事不要相互打扰。

软件研发要避免的四大误区，软件研发的各种各种理论方法，本质是围绕实用来进行设计的，一切架构、设计、研发管理方法都应该是属于实用主义。

1. 技术上的主次混淆。比如一个团队负责业务开发， 在执行过程中发现缺少一个基础组件，所以安排员工自己去做这样一套工具组件出来。后续推广、维护。
2. 管理懒惰与重度规范化问题。有人专门做规范化工作、列入KPI，结果除了这个人其他人都不关心规范化
3. 架构经验的拿来主义，要了解这个经验它是怎么来的，经验创造出来的一个过程， 推导这个经验的过程，需要大量的实践与深度思考同时进行。
4. 性能洁癖主义。

管理规则与管理责任

梁汝波：10万员工的组织如何保持活力？ 在绩效强制分布的情况下，管理者和一个绩效不够好的同学沟通，可能会这么说：“其实你表现挺好的，但是没有办法，公司有绩效分布的要求，这次只能委屈你一下。”类似这样的情况，其实是管理者没有把真正的管理责任承担下来，而是把压力转到规则之上，这样只是完成了一个管理动作，并没有起到管理效果。我们的做法是，让管理者对自己的管理决策负责，虽然这会让管理者在挺多时候处在一个有些拉伸、不够舒适的状态。

另一个挑战是，由于规则少，特别是明确的规则很少，大家在做决策时就要做很多考虑，要根据具体情况来进行决策。大家要为这些决策负责，经常需要通过讨论、会议，在更大范围内对齐，这样不仅大家的决策压力大，效率也不高。这也让很多人在管理活动中一直处在一个不舒适的状态里。管理者会很有动力去推动公司建立更多更明确的规则，这股力量像重力一样，一直在把公司往更多规则的方向上拉。但另外一方面，我们在现实世界遇到的管理问题复杂度很高，我们没有办法通过一组规则去控制、去刻画或者去应对这些管理的复杂性，我们需要留有弹性，让管理者能够做出合理的管理决策。这个度的把握是很难的，特别是在组织快速增长时，既要保证管理的有效性，又要做到公司不因管理低效而瘫痪，我觉得这也是我们一直在面临的挑战。

在一个大规模的、多元业务且快速发展的全球化组织里，如何做到可延展并且有效的管理？目前字节的做法是：通过文化来增加共识，减少规则；通过基本管理机制来实现管理效率；通过让管理者承担起管理职责来保证管理的有效性；通过数据积累和透明来实现管理反馈和迭代；通过工具系统来支撑这些的实现。在这个过程中，我们要抵抗组织的重力，一直处在拉伸的状态。

陈军：程序员的思考方式基本靠经验或者是自己见过的，归纳法，也就是先看见再相信。而大佬则使用演绎法，就是先大胆猜测一个结论，然后小心验证，也就是先相信再看见。很明显后者适用范围更广，可以处理更多的难题。对时间管理的理解也不同，程序猿也知道四象限管理自己的时间，但是时间管理的本质是目标管理，大佬对和目标没有关系的事情根本不会做，并且大佬善于定目标、拿结果、复盘，而普通程序猿对目标都是模糊的。

如何提高技术Leader的思考技巧？leader不仅要有解具体技术问题的架构能力，还要具备团队管理的能力，更需要引领方向带领团队/平台穿越迷茫进阶到下一个境界的能力。所以通常来说技术Leader的技能是虚实结合的居多，繁杂的工作偏多。

1. 很遗憾很多团队的技术规划都只是基于当前问题，有多少资源，然后采取量力而行的方法在对事项优先级进行排序。这其实不是真正的规划，最多算是计划（如果做得不好，计划都算不上，只能算是列表整理）。
   1. 很多Leader不敢向前思考，担心自己的对未来的判断不对。有这样的担心可以理解但是对事项推动无意义，因为：对上你的信息更细致，对下你的信息更全面，如果你都不能对未来做出好的判断，别人如何能够替代你做出判断；只要你的判断合理有逻辑，能够与大家达成共识，那至少说明这个判断不会太差，也是当下比较好的思考了，未必要追求绝对的正确，况且是不是真的正确只有变成了历史才知道（有时候往往历史也回答不了这个问题）；一个低价值的100%完成的目标 与 一个高价值的90%完成的目标，未必一定是100%完成就能拿高绩效，关键还是要看对组织的价值贡献。
   2. 只有向前思考，没有向后倒推。
2. 没有量化就谈不上优化，所以在定义和推动解决一个命题时，要尽可能地把遇到的问题用数据指标的方式进行量化思考。
3. 很多决策看起来都挺对也很有价值，但出发点可能是基于管理需要而不是一线同学工作的必须。这带来的问题就是迟迟无法落地，变成上有政策下有对策。

许晓斌：提高团队效率的核心还是提升开发者的体验。

1. 首先，给他们设置有挑战有意思的目标，激发团队；
2. 其次，在组织结构和系统架构上设计比较合理的高内聚低耦合的边界，让团队同学可以用更多的时间去思考如何解决技术/用户问题，而不是浪费在沟通和消耗上；
3. 还有，就是建立比较好的工程师文化和氛围，关注工程质量，而不是整天在所谓的“代码屎山”上工作；
4. 最后，就是给他们提供最好的工具，无论是 AI 的也好，还是我们称之为平台工程也要，这也是我团队为阿里巴巴整体在做的事情。 技术管理者需要同时兼顾技术和管理，二者缺一不可。在实际的工作中我看到的优秀管理者，都是两者同时成长的。如果只做管理，缺乏对技术深度的理解，就会在风险的识别，人员的任用，系统的合理架构设计上出现许多问题。反之，如果只关注技术，缺乏对人的理解和关心，那随着团队变大，各种冲突、矛盾就会被方法（是的，有人的地方就有观念差异和冲突），管理者很多时候是在基于对每个人的理解和认同的基础上，去建立团队的共识和积极的氛围，是一件解决工程师团队规模 Scalability 的事，即随着人员的增多怎么保障平均每个人的贡献不下降。

cto

CTO就是要给CEO扫清障碍和风险在波浪式发展过程中，技术在每个阶段起的作用不一样。在入轨的阶段，CTO应该是整个公司业务一号位班子的成员，是支持一号位的二号位，班子一起看清方向，把业务带入正轨。一旦入轨之后，业务进入快速增长期，CTO的核心不是看方向，而是怎么做好技术，这时首席架构师会变得非常重要，技术让业务更高速增长、加速成长，业务不要被技术拖慢增速。CTO和团队在一起要有一个面向未来的思考，不只是当下与业务的连接。未来是什么，关键的路径是什么，核心的几场仗是什么，这是CTO的牵引力。面对任何技术风险不能只是看，要亲自去试，需要公司投入一些有价值的浪费。

中台的优点在于可以减少很多重复建设，让业务可以基于中台快速创新，因为重复建设的繁忙约等于效率低下。但阿里巴巴的中台已经非常完善了，开始进入了另外一个阶段。当我做一个新业务的时候，我需要跟这么多中台打交道，需要他们去支撑我，过程中如果有任何一个中台支持不能到位，我的业务可能就做不成。我们现在开始大力推动中台能力进一步升级，改善中台的交付方式，把中台再升级。这里涉及到很多技术架构的变化。PS：中台做的厚与薄要看情况，即使是薄中台（比如仅做统一的数据收口），也是有价值的。

前台，面向业务的，为客户赢;中台，是能力中心，中台的客户是前台，让前台更加高效，让前台更有竞争力；底层后台，是强调技术先进性的，确保业务永续。这个组织每一层都是独立的业务经营单元，现在我们在做一件事情，让每个独立的业务经营单元都有CTO。这个CTO会对这个业务经营单元负全责。实现管理机制的核心就是把每一层之间的界面定义清楚。

CTO的一个核心工作，是怎么能够让自己不要成为团队的天花板，而是把自己当成团队的地板，用人做事。成为CTO还是用人做事为主，而不是做事用人为主。

心态

聊阿里P8、P9及以上人的水平

1. 业务能力上，技术线P8还是有危机感的，要自己负责规划业务（定义价值及方向）、负责吸引人（招聘及内转）、负责留住人（团建及分享），如果你不做，不出半年你的人员都会被‘友军’及‘竞对’挖走。
   1. 长远发展上，多学司马懿而不要学诸葛亮。自己信任和自己团队小伙伴们都强才是真的强，‘鞠躬尽瘁死而后已’这种玩法没用。
2. 工作强度上，P8和P9工作和生活是很难分开的，周末假期及半夜，都有可能有业务方电话过来需要应急及解决问题。哪怕和女朋友看着电影或在旅游度蜜月，接到一个电话还是必须要打开电脑快速解决的。
3. 心理建设上，P8需要有意识的是任何事情要从自己身上找原因，该认怂就认怂，什么事情能上升到P8的话，还不及时止住发酵到P9，P10就是事业部间的内战和冲突了。
   1. 假如你到了P8+或P9，需要具备一叶知秋的识别能力：自己的反省不应该依赖其他人的提醒。要善待那些对你的计划提出质疑的人，他们帮你思考得更清晰。不管做什么决定好的还是差的，大多数情况下你听到的肯定是一片赞美，少有人会直接及间接提醒你哪里不对劲。
4. 技术能力上，P8代码还是要很熟悉的，基础逻辑还是要有的。每天开很多会，一些会议上如果逻辑思维差一点，或者代码水平菜的人迟疑一下，很可能就接了个大锅，团队同学也会因此受苦（会上不顶压力1分钟，会后团队同学007），说话就是生产力。
5. 综合能力上，技术、业务、项目管理都要懂，很多需求方是没想清楚自己要的是什么，需要打破边界问清楚，以及帮他们想清楚。
   1. 你要能明确定义市场上你的竞对是谁，同行们都做的怎么样。市场容量有多大，某个事情的ROI如何。如果硬升成P8而实力及行业知识储备没达到就别怪别人欺负你了。如果不懂行业，业务方给你提注定达不成的目标及需求时，你连反驳的依据都没有。
6. 心态建设上，只有可能是你鼓励别人，基本不会有其他人鼓励你。P8都学会了在没有鼓励没有认可的情况下工作，明确知道自己想要什么，业务怎么发展。你自己就是个发动机，必须有自己的主见。
7. 工作内容上，大家应该玩过《三国志》游戏或者《太阁立志传》吧。和游戏里一样，内政、外交、人才、军事、排兵布阵是永久不变的主题，没玩过的朋友可以玩一下去。
8. 从情商视角看，P8的同理心要很强。解决问题的方式千千万，结果重要，取得结果的方法更重要。不会只看短期结果，也关心长期效益。KPI和OKR都只是管理工具，重要的是身边鲜活的战友，有血有肉有情绪，不是机器人也不是AI。
   1. 从情绪管理看，总会遇到让自己不满的人和事。控制情绪是基本功，换位思考，即使不满也应“知道但不点破”，难得糊涂糊涂难得。
   2. 保持谦卑，甚至具体场合，一定的示弱也是对全局的照顾，也能拿到正向的结果。

其它

来自极客时间 《技术领导力300讲》 笔记：深度 / 广度并重，我认为人的知识要形成 T 字形的结构，有一个专长的方向，这是一竖，同时要掌握相关的知识，这是一横，这两个方向是相互促进的。没有一定的宽度，其实你的专长深度是有限的，没有一定的深度，横跨的知识就会很松散，而且很难形成结构，大家应该都有这个经验，你在一个方向感到进步很慢，去涉猎一下相关的知识，很多时候就能帮你打开原来方向的困局。

在整个成长过程中，兴趣是最为关键的，所以follow your heart非常重要，只有在有足够的兴趣或梦想的情况下才能产生很强的自驱，没有足够的自驱我觉得在技术领域基本上是不可能走到高阶的，除了兴趣外，自己的优势也要判断清楚，每个不同的方向，我自己认为还是需要一定的天分的，而所谓的天分我觉得就是对个人优势的判断。