11 全局思维和持续完善体系的建立，让团队持续成长
你好，我是乔新亮，很高兴又与你见面了。
在技术管理领域，有一个很古怪的现象，不知道你是否有注意到：很多管理者，在面对团队成员的争吵时，会选择冷处理、和稀泥，也有人干脆沉默以对，直接忽略这个状况。
但你肯定知道，理论上，管理者是应该介入争吵，及时调停的 —— 不然团队士气和协作就会受损。
那为什么会有这样的情况出现呢？原因可能是多种多样的，但一个主要的原因，可能是缺乏全局思维。注意，这个评价不单针对发生争吵的双方，也针对不作为的管理者。
只要是争吵，情况一般都比较类似：双方各有各的道理，互不退让。作为管理者，也不想影响任何一个人的积极性，所以两头为难，干脆不管。
其实，如果缺乏全局思维，就会经常面临这样的决策难题。有个成语叫作“盲人摸象”，意思是说，几个盲人要通过触摸大象，来描绘大象的形象。于是，摸了象牙的人说，大象像一根长棍；摸了象腿的人说，大象像一棵大树；摸到大象肚子的人说，大象像一堵墙……
他们说错了吗？站在个人的角度，没错；但站在全局的角度，可能每个人都错了。很多管理层面的问题，其实都可以用“盲人摸象”来形容，道理极其相似。吵架，只是缺乏全局思维造成的众多问题之一。
2019 年在环球易购时，我就经历过这样一件事。
高可用设计或许是个“伪命题”
在环球易购，我们主要做的是跨境电子商务，服务遍布很多国家和地区，其中有一条线路，是通过光缆连接美国达拉斯到深圳的机房。
我去了没多久，在检查基础设施的高可用建设时，发现线路居然只有一条 —— 很明显不符合高可用设计的思想。因为光缆是有可能被挖断的，底层基础传输网络的抗风险能力太差。
作为技术管理者，看到了风险，当然要想办法解决了。
但着手解决时，相关业务部门却不愿意为新增加的光缆付费，说目前部门的压力大，不愿意承担这个费用。听到这种说法，我带领的团队对此很是不屑一顾 ——什么压力大，简直就是不懂啥叫高可用。
你看，一个典型的问题场景出现了，技术人员在想：明明有问题，不想着去补救，出问题的时候可别找我；业务部门想的是：我这业务压力这么大，你还要纠结什么架构设计，啥也不懂。
站在各自的角度，他们说的都对，根源在于看问题的视角不够高，缺乏全局思维。
我和我的团队说，首先，我们要学着去理解业务部门；然后，我们来分析下，对于企业而言，这种设计到底有什么样的风险。
其实，这条光缆的问题不会对 C 端业务造成影响，只会影响后台的统计分析。接着，我们向上看，根据过往经验分析：如果光缆被挖断，相关业务会中断多久、影响范围有多大？
最后，技术团队将相关调研整理、总结，和业务部门坐下来相互对齐，得出结论：业务影响处于可以接受的范围，结合公司情况，暂不增加备用光缆。
到我离开环球易购时，其实这条线路仍然只有一根光缆。光缆也被挖断过，但无论是 IT 部门还是业务部门，都能接受这个结果，没有争执和推诿。因为这是站在全局视角，大家研讨得出的结论，虽然有利也有弊，但都在预估范围内。
你看，当我们去各类技术会议学习分享时，大家经常探讨高可用、高并发的架构设计。但在实际的工作中，这类设计不一定能实现，甚至也不一定在当下对于公司是最合理的。
类似的问题还常见于中台建设。
这两年中台特别火。很多技术 leader 好不容易把中台研究明白了，觉得这个设计思想好啊，回去就要搞，结果业务部门不愿意，说：
“你说做中台、做中台，说了半天就是架构更好了。我们这个月的 KPI 都要完不成了，还要支持你做个半年不见效的中台？”
于是，技术 leader 把自己气得够呛，觉得这哪叫“技术驱动型科技公司”，没有一点长远眼光，自己留在公司就是浪费青春。
那么这又是一个有关全局思维的问题，我们要回答的，其实不是中台在架构方面的优劣势，而是在半年以上的时间维度里，中台对于整个企业，在营收增加、业务增长方面的优劣势。
如果说得清楚，其实业务部门也有不小的接受可能，因为大家不但需要考虑短期增长，也会追求长期增长；如果说不清楚，其实中台做了也是白做，属于管理者自己没想明白。
所以，在前面的章节里，为什么我总是强调：研发团队要有业务思维，业务团队也要接受技术指标考核呢？一个重要原因，就是要赋予双方更高维度的视角，让大家在工作中有全局思维。
全局思维与向上管理
当然，以上我们说的全局思维，都是站在更高的维度，将技术视角和业务视角统一起来，学会用业务增长的思维看待技术建设。
但全局思维又不仅仅局限于此。很多人觉得老板的问题很难回答，因此比较怕和老板对话，为什么呢？因为和老板相比，你缺乏全局思维，格局不够高，因此面对老板的提问，常常感觉出乎意料、难以回答。
而这一点，在每一个职级都会有所体现。一般情况，在同一家企业内，CTO 的全局思维通常强于技术总监，技术总监的全局思维通常强于技术经理，而技术经理又强于普通程序员。
会出现这种差异，当然有信息不对称方面的原因，但同时也有思维格局上的高下之分。比如，很多企业都在推行“公开透明”的企业文化，但基层员工仍然和高层管理者在思维层次上有极大偏差。为何？因为从上到下，没有培养全局思维的意识。
每次周会，都会有许多下属讲自己的工作情况，我的回应经常是：“你说的都对，但这个有什么用？产品是什么，用户是谁？对用户有什么好处，对公司有什么益处？”
请注意，我不是在质疑或者否定下属，而是在强迫下属站在全局的视角去思考。
刚才我们讲的是自上而下的思考模式。这段时间，也有很多同学留言说，乔老师，能不能讲讲向上管理？其实向上管理，就恰恰相反，属于自下而上的思考模式。
很多 CEO 其实很讨厌“向上管理”这个词，一是听起来确实让人不大舒服，像是在沟通中，掺杂了很多心机和花样；二是在很多 CEO 眼里，“向上管理”属于伪命题：是 CEO 真的需要被管理，还是下属自以为比 CEO 更明智？
听起来，是不是有点耳熟？对，这其实和下属吵架有一个共同的逻辑：双方都没说错，只是视角局限在自己这一侧。
所以，所谓的向上管理，其实不像很多新媒体文章说的一样：说话先赞同再反对、和老板培养感情，等等。
这些当然可以做，但都只是锦上添花，属于沟通技巧，不算向上管理。真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通。
不然的话，你的所思所想跟老板压根不在一个频道上，怎么“向上管理”？时间长了，老板只会觉得你自以为是、恃才傲物。
那么如何培养全局思维呢？
说起来倒也不难，主要是从两个维度去尝试重新思考问题：一是时间维度，二是空间维度。
所谓时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。比如技术人员要考虑，站在业务部门的角度，会如何考虑这个问题？站在财务部门的角度，会如何考虑这个问题？站在 CEO 的角度，会如何考虑这个问题？这是个人所处空间上的变换。
你可能会想，听起来很简单，就是挺累啊，一个问题要在不同的角度思考这么多遍，烦死了……
其实，这就是思维和认知能力养成的特点：说起来都不复杂，但做起来需要绝大的毅力和耐心。在我们专栏的第一章，大部分认知能力都存在这样的学习特点。但与第一章的许多认知不同，那些属于个人成长相关的认知，而全局思维属于团队管理方面的认知：管理者不但自己要具备全局思维，还要让团队也拥有全局思维。
这么难养成的认知，怎么传递给团队呢？这时就需要建立持续完善体系，让团队持续成长。可以说，如果没有持续完善体系，团队根本就不可能具备全局思维。
CTO 也可能犯错
在向团队灌输全局思维时，你可能会很头疼。因为有时团队就是不理解、就是不接受，甚至会表现得很偏执，让人只想在心里骂娘。
这时，你要提醒自己：既然大家都通过了公司面试，就说明基础能力还是有的，没人真的是傻瓜。团队是能进步的，要给团队进步的时间。
其实我们专栏从上架到现在，我一直在重复这句话。很多管理者，表面上支持“试错容错”的文化，但骨子里就没期望过大家会成长。
哪怕是 CTO，都会犯错，何况是普通员工呢？不给大家留出成长的时间和空间，怎么带领团队打胜仗呢？
2015 年年底到 2016 年年初，我在苏宁工作，曾带着团队做关于容器编排的技术选型。当时，针对容器编排管理工具，有两个选择：一个是 Swarm，另一个是 Kubernetes。
当时我们确实是努力站在全局视角去思考的：
在当时，Swarm 的架构简单，是 Docker 内嵌模块，部署运维成本低，在业务角度有利于降本提效；Swarm 是 Docker 的原生编排工具，支持度好，容器的启动速度高……
相比之下，Kubernetes 当时的情况就有些不尽如人意，所以我们最终选择了 Docker + Swarm 来做容器化改造。
结果，还不到一年，我就知道自己做了错误的决策。你可能也看到了，Kubernetes 后续的成长速度非常惊人。于是，我召集团队，承认了自己的失误，立刻做了调整。
后来复盘这件事时，我发现，在做技术选型时，我们少考虑了一个关键因素：大厂的支持能力。如果再有类似的选型工作，我一定会将大厂的支持能力作为重要的选择条件。
但回到全局思维这件事上，犯错实属正常，哪怕是 CTO 也一样。就像我们常做的 A/B Test，这本就是体系建立工作的一部分。
所以，当你实践这一讲所收获的认知时，如果有不耐烦、不如意的时刻，一定要提醒自己：不要急，这很正常，这些都只是成长的浩瀚大海中的一朵小浪花，都是建立持续完善体系所需的正常工作。
结语
这一讲，我们重点聊了聊管理维度的全局思维和持续完善体系的建立，这是一个不断迭代的过程。
一个组织就如同一个人，如何让这个组织有格局，并且能快速学习、持续迭代，是管理者一个重要的能力。迭代，就意味着前面有不完美的地方，在全局视角下具备纠错能力，用更短的周期、更快的速度持续完善，这样组织能力也会随着时间，不断登上新的台阶。
最近，我和一些 CEO 聊天，问他们过去在管理上最大的失误是什么，有好几位都是想了半天也说不上来。为什么？不是因为没犯过错，而是因为对于他们来说，试错、迭代都是正常流程，被正常迭代掉的问题能叫失误吗？当然不能，那本来就是规划之内的情况。你想想，自己和这些 CEO 是否有这种认知上的差距？你能否以同样的心态，看待自己的成长？
我相信，你一定能做到快速成长。或许现在，也可能是未来的某一天，你也会是那个“没犯过错”的 CEO。
今天的内容到这里就结束了。下一讲，我们会重点谈一谈，在具备了全局思维后，如何在战略上做聚焦、做取舍，真正做到 CEO/CTO 级别的认知协同，为跨上新的台阶做好准备。
我们所讲的管理者“三板斧”、管理哲学、全局思维、战略聚焦等内容，都是关联在一起的，你在看的时候，要注意前后对照，串联起来。这样的成长才成体系，才不会有失偏颇。
如果有问题，欢迎随时向我提问。我们下一讲再见！
- 海盗船长 👍（55） 💬（1）
当发现讨论的氛围不对，言语越来越激烈时，我会说一句：我们这次讨论的目标是什么？基本这句话一说，可以避免吵架。
2020-11-18 - xiaozhi239 👍（22） 💬（3）
真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通。 这个总结真的太好了。分享一个战术上的个人小技巧，可以常常问问自己的leader当前最大的烦恼是什么，最高的优先级是什么，在考虑什么问题。然后把问题揽了或者帮忙解决。这样能获取信息，也能校准自己的context，强迫自己站在leader的角度看问题。一般leader也很乐意，省了他的事，还培养了下属
2020-11-25 - E 👍（20） 💬（2）
乔老师的“全局思维”是终极目标，这个阶段需要慢慢来达到。我在自己实践和给同事以及团队交流时，一个更容易让大家接受的观点是，告诉大家要能“理解你的上下游”，要能理解对方的工作内容，站在同一语境下沟通，不能鸡同鸭讲。
2020-11-18 - 术子米德 👍（13） 💬（1）
🤔☕️🤔☕️🤔 即使还在全局思维搭建的路上，也得有个招数来拆解各种争吵，毕竟大家对于一件事情能争起来，本身就表示这件事情值得去处理好 有个叫“拉波波特批评法”，分如下4个步骤： 1）说清楚对方在说什么 2）说出对方的优点 3）说出哪些值得学 4）再说你的观点或评价 这个方法用到我们的技术评论，会议室里的争吵声音，明显下降，甚至消失。我好几个技术伙伴告诉我，很久没吵架了。
2020-11-20 - JianXu 👍（10） 💬（1）
乔老师，关于Swarm 和 Kubernetes 的这件事，我想多问几句，如果为了提效，在当时您面临的情况swarm 上线和Kubernetes 上线时间成本差别有多大？Kubernetes 还是比较复杂的，要玩好并不容易。我问这个问题有一个原因，我们公司在edge 做Software HTTP proxy 的项目当年选型用了Contour , 而现在公司里另一波人在搞Istio。 contour 主管的理由是contour 对于我们处理南北流量是最简单的选择，我们是为业务服务的，为什么要花这么大的力气去搞Istio 而延缓对业务的价值输出，Kubernetes 三百万行代码我们投入了多年时间和大量资源，凭什么我们觉得靠现在的投入就能驾驭两百万行代码的Istio. 而搞Istio 的人认为Istio 才是将来的方向，Istio 虽然有两百万行代码，但是我们可以先部署南北流量管理的模块这样真实在现阶段需要吃透的代码量就大大减少，Istio 有大厂谷歌背书，而且也为将来推进service mesh 做了准备。至于业务价值，基础架构离终端业务有些远，安全方面的要求真的到了基础架构也有很多实现的方法，至少到目前为止没有那种黑白分明的清晰决断。我想咨询一下，乔老师你怎么看你当初做出的Swarm 的选择，真的就觉得完全是错误决定吗？乔老师又怎么看我这个现实的案例呢？
2020-12-23 - 骄之 👍（6） 💬（1）
乔老师可谓「传道受业解惑」者之大成。 作为一名普通程序员，还有那么多专业的课程等着我去学习，不知怎么膨胀的，果断订阅了 CTO 的专栏。现在想想，应该是您那篇开篇词给了我莫名的启迪。 我入行较晚，同龄人很多都在做技术负责人了，而我也就算是个中级开发吧。去年，凭借自己的综合能力和机缘巧合，来到深圳一家互联网公司做技术负责人。说实话，真的是力不从心，技术方面大多是现学现卖，公司的产品流量大并发高，经常出问题，压力很大。今年中期的时候，身体也垮了。后面来了一个更强的技术，我也算是卸任了，辅助他一起支持产品的发展。 我对自己要求很高，列了一份三年的课表，里面不止涵盖技术课程，还有商业、运营、管理、思维模型方面的内容，看了您的专栏，又加进去了财务课程。我认为，一个人在具备了自我规划和执行力的情况下，一定要「政治正确」地向前走，有正确的价值观指引自己，过程中出现的问题都要有正确的思考方式。 很幸运，我需要的，您都讲到了，同时纠偏了我很多不成熟想法，甚至您上篇评论区回复的合格 CTO 要具备的素质，跟我们 CEO 讲的都不谋而合。其实还是自己眼界、格局的问题。 很多专栏都在讲「术」，帮助大家完善武器库，提升个人价值，但是您传授的是「道」，走在康庄大道上的人生，注定不会差。 再次感谢。
2020-11-19 - 秋 👍（4） 💬（1）
> 真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通。 这个说起来简单 其实还是非常难的。以个人为例，在工作上和被新的大佬交流中被教育了半年突然开窍了 认知到了下一个台阶，瞬间理解了大佬的思维。但是想想有时候如果没有一些工作上的案例，如果只是领导指示，其实很难让下属拔高思维。 乔老师有没有什么诀窍 帮助下属提高思维？ > 给大家留出成长的时间和空间 怎么平衡留出成长的时间 和 业务需求对组内成员的要求？
2020-11-18 - dbtiger 👍（3） 💬（1）
乔老师您好！ 我的收获： a.全局思维：换位思考 想咨询的问题： 1.真想开个”家庭问题纠纷处理专家“的专栏。du鸡汤说：“家里不是讲理的地”，我不以为然，家庭矛盾更适合用理性来彻底解决，感性只是神经麻痹的yapian并不持久。 本文提到的全局思维是否能移花接木到家庭矛盾化解上呢？哈哈......
2020-12-03 - Weehua 👍（3） 💬（1）
真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通。 自己总结反思，一直觉得自己向上管理没做好，也一直在思考有什么方法和技巧可以用。今天看到乔老师的这句话，顿时醍醐灌顶，茅塞顿开，一针见血！每次都有收获，值，太值了！期待后续的文章！
2020-11-18 - Love.FF 👍（2） 💬（1）
一个是要有全局思维（可能大到企业愿景），一个是要经常换位思考（对方的业绩目标）。还有，乔老师说得很对，就是谁都可能犯错，对新的事务，谁都有认知的过程。各方都应有包容心。在这个基础上，就容易做到用有效的方式表达己方的意见。
2020-11-22 - adang 👍（1） 💬（1）
向上管理培养全局思维，把自己的思维拔高，我的心得是，首先，自己向前一步有思考和总结；然后是"让领导请我喝咖啡"聊，聊我的看法和思考。大家职级不一样，获得的信息不对等，看问题的视角不同，对问题的理解会有偏差，充分利用上级这个资源获取更多的信息，观察上级思考问题的维度，慢慢培养自己的这种思维。当然这样做是有前提的，领导率先释放我是可以被利用的资源的信号，另外，在沟通的过程中领导认真的倾听和给予充分的肯定，让我感觉我被看见了。
2021-02-10 - 谷常生 👍（1） 💬（1）
这一讲要结合《07 | 组织调整到位》学习。 > 组织架构是公司协作的基础，它决定了各团队如何思考、如何协作。 > 如果能够影响公司的 IT 策略，一定要通过利润和营收，考核 IT 产品给业务创造的价值，同时考核业务部门的 IT 化水平。 > 研发团队要有业务思维，业务团队也要接受技术指标考核呢？一个重要原因，就是要赋予双方更高维度的视角，让大家在工作中有全局思维。 通过 Swarm vs Kubernetes 的案例，想起「没有完美的个人，只有完美的团队」这句话。 「沟通创业价值，分享带来快乐」，坚持留言的第 5 篇。
2020-11-20 - 张浩 👍（1） 💬（1）
之前听到过，当员工的时候，要站在老板的角度去思考问题；当老板的时候，也要站在员工的角度去思考问题。作为员工，经常站在老板角度去思考问题，也是培养全局思维的一种方式。
2020-11-19 - Learning cat 👍（0） 💬（1）
您好，您的这节课我反复听了。我们作为技术人员，也和别的部门有过想法的冲突，也影响过自己的情绪。我觉的您讲的全局思维帮我把这个问题想的更透。通过练习从不同角度思考问题，相信以后工作中的团队合作会更顺畅。
2021-03-18 - RMB 👍（0） 💬（1）
乔老师，非常感谢您的分享，以前我做事情的时候就有个方法，从整体再到细节，看了您的专栏，才知道是全局思维，再学习您的总结，有种豁然开朗的感觉，非常感谢。 而且，您的专栏分享，也是从全局的角度，给大家理清方向，个人认知、管理、专业技能，对于做技术的我，正是我长久以来一直寻找的，对以后的学习有了更清晰的轮廓。 最近一直再复习您的分享，感谢。
2020-12-23