CTO直接辞退了一名架构师

近期从圈子里面了解到一个架构师朋友直接被CTO辞退了，这个朋友也是很郁闷，找我来诉苦，我大概和他聊了一个小时，我大致复盘了一下他的经历，并按照如下几个部分去阐述。

旧的工作模式

这个朋友在架构师的岗位上干了快5年了，也就是说他一直是该公司某产品的架构师，职位一直没变，那么他这五年就是一直在原地踏步的做事情，算是比较安逸的，并且团队当中也没有人能够去挑战他的位置，他又熟悉业务，技术也还算可以的，所以做事情也还算快。

他的工作模式大致可以总结为如下几条：

（1）他参与了公司业务项目从0到1的演进，并落地了一些项目，原先的功勋成员，要么就是特别优秀，已经进化为业务线的BU负责人或者业务负责人，要么就是负气离职，并另起炉灶了，只有他由于懂业务，但是能力还达不到升级为中层或者高层，就给了他一个架构师的头衔；

（2）经历了前几年的辛苦之后，这几年基本处于养老状态，平常就是参加一下业务评审会议，评估一下产品等等，自己的技术老本都快忘关了，因为他除了参加业务评审之外，也还是参加技术评审的，但是基本都是评审别人的，很少有看到他自己的技术方案的，久而久之新来的开发总是觉得他有点倚老卖老，但是又没办法，业务领导又是和他一起成长起来的初传员工；

（3）他的业务能力、架构能力、技术能力和管理能力基本处于停滞状态，只是他在团队当中的威望和资历很深，大家都亲切的叫他“什么什么哥”；

（4）久而久之，他也觉得太安逸了，也想去做点事情，但是像自己的领导去反馈，并提出了一些建议，但是大多数都是被否决了，主要由于缺乏接地气的方案，又没什么太大的价值，那么慢慢的随着年龄的增长，他也觉得还行，就这样凑合着过吧，反正自己的职位也升不上去了，只要业务稳定，产品稳定，自己也不至于没工作是吧。

山崩了

2020年一场肺炎，就彻底改变了这个朋友的生活状态。

原先稳定的产品变得不稳定，业务停滞不前，CEO非常不满意，导致CTO也换了，那么他的顶头上司，也就是一直保护他的领导也受到影响，也就是说原先的初创员工，基本都要走了，但是人家毕竟已经混上高层了，所以人家走还是蛮轻松的，都进了那个圈子，但是他不一样，他是在原地踏步。

新来的CTO是一个实干家，也就是一个拿业绩说话的，所谓新官上任三把火吗？当然他得知会有新的CTO上任之前其实也知道消息的，当然他也考虑过一朝天子一朝臣的道理，也想要走，但是确实能力有限，没那么快的找到下家，当然原先的老领导也知道他的能力乍样，也都委婉的拒绝了他的跟随，毕竟人都是现实的嘛。

他也就硬着头皮去迎接这位新的CTO，毕竟他是现在公司当中唯一一个最熟悉业务的初创员工。

这位CTO来的时候，也是找了团队当中的每一个Leader及手下的员工去聊过，当然也找这位独立在Leader之上，并和总监对齐的架构师聊了好久，CTO也汇总了最后聊天的结果，并且自己心里也有数了，知道目前业务团队是一个什么状态，哪些人是实干家，哪些人是在养老，当然这位朋友就被列入养老状态了。

改革的替罪羔羊

CTO开始改革了，也就是按照自己的思路对业务产品的人员配置进行重组，当然都是择优留用，当然首当其中的就是考核一线的Leader、技术总监还有这位架构师朋友。

当然这位朋友也是很拼，基本上那段时间也是没日没夜的加班，几乎是拿出了自己之前在业务团队中立足的看家本领，具体做了哪些事情了，大致如下。

（1）查漏补缺的整理了很多以前本来应该输出的业务产品设计的文档；

（2）整理了一些历史遗留的技术和业务问题，并也给出了一些技术和业务建议的方案；

（3）并利用自己目前对业务的理解能力，输出了一套比较完整的业务架构方案，供CTO的学习业务金额了解产品；

（4）配合产品团队，也输出了一些产品体验和优化的产品层的建议，并也形成文档，进入知识体系；

（5）对于现有人员的配置也给出了一些建议，并也给出了自己的整改的一些建议，哪些团队需要优化，哪些团队需要补充新鲜血液。

总之，他做了很多他以前都不会主动去思考和梳理的一些事情，都是为了迎合这位新来的CTO。

但是这位架构师有一个毛病，那就是只会做方案，尤其是自己熟悉的业务产品的业务架构方案，以前总是把原有的业务方案，改吧改吧就可以用酒瓶换新瓶的方式去瞒天过海，毕竟都是老熟人，但是现在不一样了，这位CTO是新来的，并且是一个见过世面的CTO，也就是说这位朋友自认为非常高大尚的业务架构和技术架构方案，在这位CTO眼中，确实是太LOW了，只是碍于情面，CTO并没有表露出来，毕竟也做了很多事情。

CTO和这位架构师接触了一段时间之后，觉得确实毛病很多，但是能力一般，感觉是可有可无的，于是就动了心计，决定挖一个大坑给他。

怎么去挖了，那就是开启一个全新的业务产品项目，叫这个架构师负责这个项目，并提拔为业务负责人，当然架构师非常开心啊，毕竟是晋升了，也非常愿意去做这件事情，但是他不知道这个事一个巨坑。

新的业务项目是一个完全从0到1的项目，但是这位架构师，由于一直停滞不前，以自己现在的能力是没办法胜任这个岗位的，但是他不知道，以为很简单不就是重新做一个业务项目吗，并且也是横向的业务产品，那岂不是轻车熟路的。

但是他不知道，他自己挂的这个职位“业务负责人”的含义，相当于他要为这个业务产品的落地负全责的，但是CTO对这个项目非常重视，到外面也到处宣传了，目的就是要大家都知道自己对项目的重视。

一方面呢，也是要历练一下这位架构师，看他能不能够借这个项目去成长，并逼一下自己，将自己的能力提升上去，并匹配这个岗位；

另一方面呢，也是有自己的小心思，既然这个新的岗位已经出来了，如果他不合适，就立马可以直接开除了，并再招聘一个新的有能力胜任这个岗位的人过来，当然大概率就是自己以前的老友或者关系户，或者是上家公司的领导班子，只是还有一段时间的“竞业协议”的缓冲期，刚好可以拿这个项目做拖延。

总之，无论怎样都不会很大程度上去影响到自己在公司的仕途，因为这位CTO除了力推这个项目之外，他还会推自己比较擅长的项目，并进行改革，并将直接负责人的角色挂在自己的名下，聪明吧。

结果可想而之，这位朋友最终做失败了，项目交付不理想，这架构师在升职之后的考核期之内（通常是一年），就被开了。

那么这位CTO就顺理成长的向高层建议，再由他重新招聘一个合适这个岗位的人过来，这个通常都是很多高层的玩法，叫做先利用自己想要开除的人，创造一个更高的岗位出来，然后再以能力不能胜任唯理由去开除，然后再提这个岗位招聘一个自己真正的心腹来。

所以大家一定要谨记一个道理，在公司空降高管来的时候，不要以为高管信任你，将你当作自己的心腹去对待，并提拔你，你就高枕无忧了。你要时刻记住，在利益面前，每个人都是有自己的小本本的，他之所以重视你，那是他觉得可以利用你手头的资源去做事情，并且你要时刻记住“一朝天子一朝臣”的道理。

总结

这位被提升为业务负责人的架构师朋友，现在确实知道了自己当初为什么会被开除的原因了，他忘记了自己原来是公司的历史遗老的角色，也就是说无论你怎么去做，你都可能会被认为是反对这位CTO的精神领袖，除非你做的项目是天衣无缝的，不然很容易会被斩首祭旗，让那个那些潜在的反对声音销声匿迹。

当然也并不是所有CTO是这样的，其实从职场法则来说，这位CTO的做法也没错，因为他要立足这家公司的高管层，那么他得压得住研发部门，不然这个威信就没了。

这位架构师朋友也有自己的原因，那就是在“架构师”这个岗位上安逸的太久了，而没有思考自己将来晋升之后，自己该如何去做事情，并且需要具备哪些能力，本质来说就是自己停止成长了，但是当新的CTO给了它一个具有挑战性的机会之后，一下子拿不住了，从而导致搬起石头来砸自己的事情发生了。

另外我的新书RocketMQ消息中间件实战派上下册，在京东已经上架啦，目前都是5折，非常的实惠。

https://item.jd.com/14337086.html?编辑https://item.jd.com/14337086.html

“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后，又一本历时超过1年半的巨无霸技术实战类型的书籍。

为了提高读者阅读本书的体验性，本书总共设计了十个特色，下面我一一的给技术小伙伴阐述一下。?

【特色一】由浅到深

本书将RocketMQ的技术原理和最佳实践体系化，按照由浅到深的顺序呈现给读者，使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后，读者不仅能熟悉RocketMQ的核心原理，还能充分理解RocketMQ的“根”。

【特色二】技术新

本书不仅包括RocketMQ4.x（4.9.2版本）的核心原理分析和最佳实践，还包括RocketMQ5.x（5.1. 0版本）的新特性分析和最佳实践。

【特色三】精心设计的主线：零基础入门，循序渐进，直至彻底掌握RocketMQ

本书精心研究了程序类、架构类知识的认知规律，全书共分为6篇：①基础；②进阶；③高级；④高并发、高可用和高性能；⑤应用；⑥新特性，是一条相对科学的主线，让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。

【特色四】绘制了大量的图，便于读者理解RocketMQ的原理、架构、流程?

一图胜于文，书中在涉及原理、架构、流程的地方配有插图，以便读者更加直观地理解。

【特色五】从架构师和技术专家的视角分析RocketMQ?

本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理，并从架构的视角展开分析，这些也是程序员进阶为技术专家或架构师必备的技能。

以下为从架构师和技术专家的视角分析RocketMQ典型案例，读者阅读完本书之后，也能够达到这样的水准。

【特色六】不仅有原理分析，还有大量的实战案例?

本书介绍了大量的实战案例，能让读者“动起来”，在实践中体会功能，而不只是一种概念上的理解。

在讲解每一个知识模块时，我在思考：在这个知识模块中，哪些是读者必须实现的“标准动作”（实例）；哪些“标准动作”是可以先完成的，以求读者能快速有一个感知；哪些“标准动作”具有一定难度， 需要放到后面完成。读者在实践完书中的案例之后，就能更容易理解那些抽象的概念和原理了。

本书的目标之一是，让读者在动手中学习，而不是“看书时好像全明白了，一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力，这样本书的价值就会被最大化。?

本书相信“知行合一”的理念，而不是“只知，而不行”，避免开发人员出现眼高手低的现象。尤其是在技术面试过程中，面试官更加看重的是既懂原理，又能够主动是实践技术的技术人。

【特色七】深入剖析原理?

?本书以系统思维的方式，从业务功能视角剖析?RocketMQ?底层的技术原理，使读者具备快速阅读?RocketMQ?框架源码的能力。读者只有具备了这种能力，才能举一反三，实现更复杂的功能，应对更复杂的应用场景。

?【特色八】从运维的视角分析?RocketMQ?的最佳实践

【特色九】参与开源?

?本书向读者展示了如何修改?RocketMQ?源码，并快速验证案例分析。这样，读者可以从中学到参与开源的技能，并为后续自己能够参与开源做准备。

【特色十】双色印刷，读者体验会更好?

为了提高读者阅读本书的体验，在有上下两册的前提下（巨无霸，超过800页），出版社不吝啬印刷成本，依然采用双色印刷。

【推荐】本书的最佳学习路径?

?为了提高读者学习RocketMQ的效率，我这边结合我自身从RocketMQ小白到RocketMQ专家的经历，为读者汇总了一条最佳学习路径。

【寄语】作者寄语?

RocketMQ是我深度参与研究的一款开源消息中间件，无论是从源码，还是架构场景，我都提炼了很多最佳实践。

在开源领域，技术小伙伴可以使用的开源消息中间件非常的多，比如Kafka、Pulsar等，我之所以选择研究RocketMQ，除了工作内容和角色需要之外，更多的还是自己感兴趣，因此我建议技术小伙伴一定要先培养自己的兴趣，兴趣才是提升技术硬实力的第1要素。

当然我并不止研究了RocketMQ，还研究了Pulsar和Kafka等（包括开源消息中间件生态中的主流框架），只是本书作为一本关于RocketMQ实战派的书籍，我必须要以RocketMQ为主。

假如技术小伙伴想成为Java领域的架构师或者技术专家，我强烈建议你去研究RocketMQ，它会给你带来很多意想不到的技术和架构方法论的收获，这个也是我写本书的主要目的之一。

建议技术小伙伴按照本书设计的学习路线，逐章的去阅读和实战，这样学习效果会更好。

如果技术小伙伴有技术交流的，可以通过博文视点官方的读者群找到我的联系方式，并与我沟通，我会实时的解答读者的疑问。

本文公众号“架构随笔录”

本人视频号“架构随笔录”

【博文视点】2021年度优秀作者

2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”，它是我涉足知识输出领域以来的第一本书，同时它也是我自己积累的技术池中部分技术的产出。

为了写好那本书，我几乎花费了所有的休息时间，并主动的承担了书的售后技术辅导和咨询的职责（几乎是有问必答，坚持了整整两年）。

所谓有付出总会有回报，Alibaba这本书的销量还不错，我也因此获得了博文视点颁发的2021年度优秀作者。

我很清楚，这个是博文视点为了鼓励我继续去用心写书，因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。

所谓一分耕耘一份收获，我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人，希望真的对大家有帮助。

?【博文视点】2023技术成长领路人

2022年，我开始涉足技术直播和技术讲师领域，并和博文视点合作几次技术直播，直播效果还不错，再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术，并且这些技术都是有助于“技术人”快速成长的，因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项，这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术，因此只要我有时间，我就会孜孜不倦的去讲和聊技术。

【四维口袋】2022 KVP最具价值技术专家?

2022年，我开始涉足企业培训和相关技术直播，并和“四维口袋”合作了几次技术直播，并荣获了2022 KVP最具价值技术专家的技术奖项。