曾经我也崇拜沉默寡言的技术型 CTO，直到遇到了能言善道的管理型 CTO

个人经历，不一定对，只是分享下感受，莫喷。

刚毕业时面试某小厂，感觉 CTO 气场很强，我称为 A 君吧，说话铿锵有力，压得我喘不过气来，问得很深入，面完汗都出来了。入职后知道 A 很牛，在社区有点名气，做过不少开源项目，后端们非常尊敬他，有人还是奔着 A 来的。

A 非常内敛，话不多说一向独来独往，团建什么的都是坐一边点点头。技术很强，带着几个后端抗下很高的并发，在小公司孵化不少技术产品，每次项目启动会都能准确地预见问题。项目紧急的时候第一时间带头冲锋，确有大将之风。我也希望成为 A 那样人牛话不多的 geek 。

在我入职一年后，A 另谋高就了，新来的 CTO 称为 B 君吧。他刚来的时候很健谈，每天都跟同事打招呼，有时在路上遇到了，会找你拉拉家常，其实我也不太爱社交，特别是这种上下属的闲聊，不太适应。感觉他平时工作也不写代码，当时我还是比较怀念 A 的。

B 空降三个月后，摸清了公司的底细，本来我们的后端是兼任运维的，B 强烈要求增加专业的运维，运维大哥一来，瞬间解放了随时待命的后端们，还规范了 ci/cd 。招了更多前端，解放部分老前端出来配合后端给内部写工具。要求产品提需求时必须通过技术评审，开会前必须提前一天发会议资料，在评审会上开发打回了非常多不合理的需求。要求开发在写代码前先写文档，互相审阅后才能开工，项目结束后立马做复盘。还经常鼓励我们内部反馈问题、分享新技术，内部的文档平台也拉了产品和运营进来，一起写一起讨论，力排众议让设计部增加 UX 岗和增加 UI 人手。

一开始大家都不适应，我也不喜欢整天开会写文档，觉得 B 瞎搞。一晃眼三年过去了，大家完全熟悉了这套模式，发现好处真的好多：

1.以前生产环境经常有些难以出现的 bug ，日志也没报错，没收到投诉就不管了，B 严格要求后端做好分级日志，前端做好错误监控，结果真查出了很多疑难杂症的原因。
2.B 提出前后端一起审视开发中的效率问题，找出耗时比较多的环节，机械性工作（比如导数据）一律写工具解决，有了我们内部造了不少轮子，不得不说效率大幅提高。
3.产品提需求需要技术评审，提高了技术的话语权，才发现很多需求根本是没必要的，用已有的业务打通一下即可，我们经常跟产品来回拉扯，结果就是双方都更加清晰业务的核心和实现方式了，先准备会议资料再开会，开完会再写文档，真的非常高效。
4.以前的设计根本不考虑前端的实现，而且非常忙，经常是前端等设计稿，B 软磨硬泡设计部大佬增加 UI 后，UI 有了更多时间跟前端坐在一起讨论怎么设计更合理，更方便做，设计稿也按时出了。

后来我升职了，开始跟公司很多不同部门的人打交道，原来才发现很多时候其他部门以前想给我们技术部门提一些小需求，A 要求对方出文档，很多不懂技术的同事就不敢提了，由于 A 平时也很少话说，其他同事基本都是见不到的，所以都不敢提建议，只有重要的业务需求才会让产品提出正式的需求。
B 来到后，大群的气氛明显开始活跃了，其他部门也敢聊敢提一些小需求，才知道其他部门用自家产品也有各种痛点，比如内部有些申请经常同步失败，部分基层员工叫苦连天，以前 A 都说接口没问题的，测试也没复现，也不是什么大事情，就叫他们重启网络算了。后来 B 在闲聊中知道这个情况，特意找了个时间安排技术去跟进，原来才发现真是一个远古 bug ，解决之后其他部门的人真的非常感谢 B ，虽然这都是小事，但我真能感觉公司的人相处更融洽了，我真心佩服能把大家团结到一起的这种人。

changnet

2023-02-13 21:13:34 +08:00

@Admstor 我认为技术行得：满足需求，健壮吧。能攻克技术难关，说是实力是有的，这叫满足需求。“生产环境经常有些难以出现的 bug ”，B 加几个日志，就查出了很多疑难杂症的原因，这健壮性完全不行。

他这种属于思维比较强，但技术实现特别差的，我遇到过好多这种人。有什么问题，即使比较难，也解决得特别快，但是完全不注意细节，接口难用不考虑实际业务需求，bug 多也不修（反正他实现了，别人调，又不是他负责任），在团队里比较难相处。

这种我就称为技术一般的，因为他的技术缺陷拉低了他的水平。至少你说他很忙没时间修或者压根就不对这个项目感兴趣了，那是另一码事，我原本也有说。