这是一个创建于 682 天前的主题，其中的信息可能已经有所发展或是发生改变。
个人经历，不一定对，只是分享下感受，莫喷。
刚毕业时面试某小厂，感觉 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 ，虽然这都是小事，但我真能感觉公司的人相处更融洽了，我真心佩服能把大家团结到一起的这种人。
刚毕业时面试某小厂，感觉 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 ，虽然这都是小事，但我真能感觉公司的人相处更融洽了，我真心佩服能把大家团结到一起的这种人。
 |
1
yfwl 2023-02-13 16:30:17 +08:00  5
这么说 B 懂技术，懂管理，能把一个团队带的很好啊。
|
 |
2
LaGeNanRen 2023-02-13 16:32:34 +08:00 4
但是 b 加了很多成本，老板就不乐意了啊
|
 |
3
vanillacloud 2023-02-13 16:52:50 +08:00 via iPhone 12
老实说，个人觉得，对广大「基层开发」而言，偏管理型的领导才是福音。毕竟领导的责任其实是领导，高管的普遍特征，正是不怎么做眼下具体的事…… 当然，A 作为攻坚组的组长，若是真牛，待遇也是随便你开。
可惜并不是很多人既能掌握技术概念，又擅长人际关系，更能看透团体之间的利益关系。 从你提到的情况，正因为 B 不会「只忙自己的事」，所以最终缓慢但稳定地提升了整体的质量——工作质量和生活质量。 |
 |
4
shinession 2023-02-13 16:55:25 +08:00
确实, 高层是不需要懂那么多技术的, 但是要懂管理, 能解决内部一些痛点的就更好了
|
 |
5
libook 2023-02-13 16:57:09 +08:00 1
我个人倾向认为，CTO 本来就是管理岗位，纯技术人员应该是高级工程师、技术专家、研究员之类的岗位。
或者说 CTO 是技术和管理的交叉领域，本职工作还是管理，但同时要有对技术的了解和敏感性。 |
 |
6
renothing 2023-02-13 17:02:55 +08:00
A 适合带小技术团队，B 适合带更大的团队，跨部门合作。
|
 |
7
w292614191 2023-02-13 17:03:01 +08:00
@LaGeNanRen #2 我一个跟头
|
 |
8
wangritian 2023-02-13 17:16:06 +08:00
A 更适合资深研发 /架构岗位，专门攻克难点，带带简单的小团队也没问题，B 是正经的管理者，懂技术也懂人性
|
 |
9
sinboy1988 2023-02-13 17:17:04 +08:00 4
B 要壮大队伍，收拢人心。还有，让每个人每个部件都可以随时替换
|
 |
10
liprais 2023-02-13 17:19:29 +08:00 19
等 B 把你开了你还说他好么?
|
 |
11
putaozhenhaochi 2023-02-13 17:23:20 +08:00 via Android
@liprais hhhh
|
 |
12
chuck1in 2023-02-13 17:25:59 +08:00
你说的这些都是好事，但是国内的公司，很可能最终会把这些好事变成坏事。
|
 |
13
onikage 2023-02-13 17:30:01 +08:00 1
前提是公司业务能支撑起这么多人
|
 |
14
daddyLi 2023-02-13 17:30:32 +08:00
像凤凰项目
|
 |
15
xalilo 2023-02-13 17:34:34 +08:00 11
A 这种遇到问题，不去定位，让人重启的敷衍态度，真的是技术牛人吗？
|
 |
16
wu67 2023-02-13 17:35:52 +08:00
要是有能言善辩的技术型领导更爽, 可惜我因为小钱钱的原因跑路了
|
 |
17
hhjswf 2023-02-13 17:40:46 +08:00 via Android 1
原本你们这小厂流程这么不规范？我感觉你们那位大佬 cto 未必很强
|
 |
18
lidongyooo 2023-02-13 17:52:35 +08:00 1
B 未必比 A 强，A 有可能是已经预见到公司的发展局限性才缺乏积极性。
B 之所以这么积极是因为他新上任，急需展开工作，向老板层交答卷。 |
 |
19
svenzhao 2023-02-13 17:52:35 +08:00
@xalilo geek 类型的人 很多时候比较自我 会轻视交互类的动作 他自己不认为的痛点就不是痛点. 其实工作了也能发现 很多人 经常看不上前端的工作
|
 |
20
RightHand 2023-02-13 17:59:53 +08:00 via Android
a 决定了技术上限，b 决定了业务上限，个人觉得如果没有 a 打下的基础你不会觉得 b 管理好
|
 |
21
lxh89910329 2023-02-13 18:00:26 +08:00
我这里的 CTO ，说是 CTO ，其实不写代码，感觉也不要他管理，因为我们已经各自有组长，业务需求流程也都已经很规范，在他来之前就已经很规范...
|
 |
22
zhouyg 2023-02-13 18:06:18 +08:00 4
B 规范流程加了很多人手，好奇业务 you 增长吗
|
 |
23
iOCZ 2023-02-13 18:11:44 +08:00
说明沟通和流程是必要的
|
 |
24
aaaaaaaaa 2023-02-13 18:29:58 +08:00 via iPhone 1
换个角度，如果是 B 先来的，靠 B 能否带着你们几个后端扛住高并发？能否让你公司有机会、有资金去招更多的人？
|
 |
25
feiwan 2023-02-13 18:36:22 +08:00
通过管理能将事做好的人本身就是很稀少...大多数都是管理和没管理一样的庸才以及更多管理了能把事情做的更差的天才。
|
 |
26
echo1937 2023-02-13 18:41:22 +08:00
内部流程规范和基础设施这块，其实属于技术领域，都是在做具体的事；
外部沟通协调，增加人力和投入，提升不同部门的沟通效率，从非技术的角度提升产品满意度，这些属于管理领域，重在搞定人， 所以 B 这方面明显是又懂技术、又会管理的 CTO 。 |
 |
27
Achilless 2023-02-13 19:18:46 +08:00
说了一堆过程，反馈到业务层的结果如何
|
 |
29
shuang 2023-02-13 19:45:47 +08:00
加个收藏学习下 B
|
 |
30
whyclong 2023-02-13 19:55:24 +08:00 via iPhone
a 可以做到 1 亿，b 可以做到 100 亿。
|
 |
31
changnet 2023-02-13 20:46:44 +08:00 3
“以前生产环境经常有些难以出现的 bug ，日志也没报错，没收到投诉就不管了” 这说明 A 的技术不行，真正钻石技术的人不会容忍自己负责的程序有 bug 而不去处理，除非忙到没时间或者对这个项目已经失去信心
完全没说到 B 在技术上的作用，只有管理上的。你们公司是否有其他专门负责技术攻关的，如果没有，他能在关键时候顶上吗？没有发生冲突的时候，B 确实好相处很多，尤其是业务扩展阶段，比 A 好很多。但当业务无法支撑 B 这种拼命堆资源的做法时，这时候你就知道他的厉害之处了。 |
 |
32
yufeng0681 2023-02-13 20:47:58 +08:00 3
B 是一个合格的商业工程师。 做事要同时看成本和收益。
初期，业务在发展期，试错期，壮大期，需要的是冲冲冲； 中期后期，业务利润上来了，产品形态稳定了，就要考虑综合成本（运维成本，业务扩展性，性能，可靠性，可用性） 让事情清晰化，减少信息传递损耗，提高团队效率，形成流程（好的流程，能降低团队 CPU 负荷，低负载运行下去） |
 |
33
Admstor 2023-02-13 20:54:56 +08:00 3
上到 CXO 下到普通码农
其实都是 B 类型会更受欢迎啊... 楼上一些担心业务啊成本啊啥的...没看楼主都说人家已经来了 3 年了吗 我不是个码农(至少不完全是) 所以有时候对 V2 一些程序员所谓的"geek"思想很无语 楼主有这样的 CTO,应该也会对自己的码农之路有更多的感想了 |
|
34
Admstor 2023-02-13 20:58:30 +08:00
@changnet
首先咱们需要定义一下,什么叫做技术不行? 至少按照楼主的描述,在 A CTO 的带领下,很多难关都攻克下来了 至于修 BUG,我真的不觉得这是断定一个人技术高低的标准 扫地僧传说毕竟是传说 尤其是现在的项目代码量也完全不是上古时期可比 特别是楼主提到了,A CTO 喜欢带亲自下场带头冲锋,这其实也证实了,A CTO 其实是没多少时间再去修 BUG 了,特别是那种非重大 BUG |
 |
35
wellerman 2023-02-13 21:01:06 +08:00 2
哈哈 OP 你就是这个 B 吧，不然怎么“软磨硬泡设计部大佬增加 UI ”
|
|
36
changnet 2023-02-13 21:13:34 +08:00 1
@Admstor 我认为技术行得：满足需求，健壮吧。能攻克技术难关，说是实力是有的，这叫满足需求。“生产环境经常有些难以出现的 bug ”，B 加几个日志，就查出了很多疑难杂症的原因，这健壮性完全不行。
他这种属于思维比较强，但技术实现特别差的，我遇到过好多这种人。有什么问题，即使比较难，也解决得特别快，但是完全不注意细节，接口难用不考虑实际业务需求，bug 多也不修（反正他实现了，别人调，又不是他负责任），在团队里比较难相处。 这种我就称为技术一般的，因为他的技术缺陷拉低了他的水平。至少你说他很忙没时间修或者压根就不对这个项目感兴趣了，那是另一码事，我原本也有说。 |
 |
37
Huelse 2023-02-13 21:35:40 +08:00
楼上这么不坏好意的吗？ B 发展的好公司也可扩大业务了啊，就一定要换人呗？有点怀疑一些公司鼎盛了立马走下坡路就是你们这种思维在作祟
|
 |
38
fuchish112 2023-02-13 22:04:10 +08:00
@LaGeNanRen #2 其他成本也许降低了呢，比如说 bug 率降低了，或者产品打磨更细致了，对效率更有提高了呢
|
 |
39
night98 2023-02-13 23:11:30 +08:00 5
你们老板能给 B 3 年时间才是关键，B 做的很多东西短期都是很难看到效果的，能一直实施下去也挺有难度的
|
 |
40
drackzy 2023-02-13 23:52:29 +08:00
遇到的能言善道一般嘴炮几率大一些。
|
 |
41
chenPiMeiHaoChi 2023-02-14 09:29:11 +08:00
10 楼正解。
|
 |
42
matrix1010 2023-02-14 09:49:42 +08:00 via iPhone
我一直在想合格的 cto 应该是什么样，从我的经验来看个人魅力出众和技术过硬至少要占一点
|
 |
43
ElmerZhang 2023-02-14 09:50:51 +08:00
A 适合没钱的小公司，省成本，B 适合有钱的公司。
|
 |
44
raptor 2023-02-14 09:58:13 +08:00
懂技术或懂管理至少要一项，有两项那就更好了，但现实中大部分是一项都不沾——说技术技术不懂，说管理管理一塌糊涂，对上只会吹牛，对下只会施压，一出问题就甩锅……
|
 |
45
nicebird 2023-02-14 10:11:16 +08:00
A 一般是作为骨干的，提升到管理是因为也没其他合适的人。
B 肯定更适合管理。 |
 |
46
UMU618 2023-02-14 10:18:07 +08:00 2
A 适合开发 ChatGPT 。
B 适合用 ChatGPT 。 |
 |
47
php01 2023-02-14 10:22:27 +08:00
B 好做，有百度，多加几个群，问大佬遇到这事怎么办要招什么人就行了。
A 难做，因为真的要懂技术啊。 |
 |
48
Oneshu 2023-02-14 10:23:09 +08:00 via iPhone
@LaGeNanRen 很明显，B 帮着老板造了一艘航空母舰，如果他不是蠢货的话就知道，有了这些框架。
整个公司可以随时替换掉不合适的零件，而不是关键节点被一个人或者一个组把持。 |
 |
49
xuanbg 2023-02-14 10:24:38 +08:00
每个公司，或者每个部门，都需要先解决生存问题，然后再考虑发展问题。A 技术虽然强，但没有建立规范的研发流程，实际上并没有完全解决生存问题（内部疲于奔命，外部怨气冲天）。B 的到来，才真正解决了研发部门的生存问题。在这个基础上，需求就要从生存变成发展（做更多，做更大）了，如果 B 解决不了发展的问题，可能还会换成 C 。
可能有些人会认为在公司规模小的时候，没有流程效率会更高。当然这种情况是真实存在的。但存在的前提是整个团队都很强，大家都知道做什么事，怎么做是对的才行。如果团队并没有这么厉害，大多数人不懂怎么做是对的的情况下，规范的流程就可以让人知道怎么去做好自己的这个环节。虽然效率不高，但至少能把事做对。所以，我是坚定认为，哪怕最小的规模，哪怕就是几个人的产品 /技术团队，也应该建立完善的产品研发流程。只有这样才能保证产品能够符合真正的需求，产品才能按预定计划和要求上线。 |
 |
50
guabimian 2023-02-14 10:28:31 +08:00
关键一句：“后来我升职了，”
|
|
51
xuanbg 2023-02-14 10:30:12 +08:00
|
 |
52
loryyang 2023-02-14 10:38:53 +08:00
所以大厂技术牛人一般不做 leader ，如果要做，得补许多管理技能
|
 |
54
kilotiger 2023-02-14 10:49:36 +08:00
A 做不了管理，所以可能 A 显得比较高冷内敛，是把握不好这种上下级的关系。相反 B 就显得游刃有余，从这个角度来看，什么人做什么事吧。
|
 |
55
tairan2006 2023-02-14 10:51:46 +08:00
一般技术大牛确实不管理啊
不过既然做到了 CTO 的位置，A 也要转成 B 了 |
 |
56
LeegoYih 2023-02-14 10:54:16 +08:00
还是喜欢我以前的佛系领导，下班就走，需求不闻，排期不问，以至于我来半年了都不知道他在干啥，但是很自由舒服
|
 |
57
bleoo 2023-02-14 10:54:18 +08:00
@lxh89910329 但是出了问题，他就得第一个上，第一个负责。
|
 |
58
zhang77555 2023-02-14 11:03:30 +08:00 1
CTO 就是应该知道怎么向老板多争取资源啊, 这个技能其实才是最有用的,也是是大多数程序员不具备的, 只懂技术的做技术专家就行了
ps:好多程序员都会有种"会扯淡"不算是能力的错觉,其实有很多"需求"就是应该用嘴解决,而不是代码 |
 |
60
zeroowtone 2023-02-14 11:13:47 +08:00
有 B 这样的领导真的很好，自己能成为这样的领导更好
|
 |
61
xdzhang 2023-02-14 11:24:27 +08:00
车模寡言现在在哪儿都不行，也不是不行，主要是不公平，大概率吃亏。
|
 |
62
anlythree 2023-02-14 11:25:54 +08:00
开发 3 年多了，见过 A 类和 B 类的领导，个人感觉喜欢 B 类的领导。至少 B 领导会顾及一些东西（即使是表面），但是相信我 A 大概不会顾及自己下属多少的
|
 |
63
christin 2023-02-14 11:34:20 +08:00 via iPhone
我觉得两者没有什么区别，都是大佬。在某方面都有过人之处，不一定非要学习某个人，可以综合一下取长补短。
|
 |
64
woyao 2023-02-14 11:37:37 +08:00
A 适合 0-1 ，小公司前期。
B 适合 60-100 ，大公司前期。 |
 |
65
everhythm 2023-02-14 11:37:51 +08:00
A 是开源，B 是节流
B 做的事其实就是提高了内部运转效率，让大家觉得“工作不那么忙” 对于个人而言，能不能像 A 那样有自己的技术生产力，可能更有个人价值吧 |
 |
66
lower 2023-02-14 11:45:28 +08:00 2
@changnet A 应该是跟着公司最初起来的角色，一般都是经历过资源人手短缺时间紧时期，辛辛苦苦搞出来一套能跑的系统，肯定能把控系统各种地方不至于出大问题；就算后面有条件可以投入更多资源，也很难有动力去推翻之前的，重新搞一套新的，或者做一些文档流程这类不会明显对业务有提升的事情；；只能说很多客观因素也会影响 A 的决策
|
 |
67
8355 2023-02-14 11:47:54 +08:00
A 的管理是提权
B 的管理是降权 提权要自己把控和负责 但很累 降权是把部分责任分给不同的人 A 的问题是不可能所有人都在全时间都能做到最好 B 的问题是效率适当降低 增加人手和成本 A 适合从 0-1 和 100-101 B 适合 1-100 只是大部分公司很难同时养活两种人两种团队 |
 |
68
god7d 2023-02-14 12:02:51 +08:00
A 这种沉默寡言的不觉得上班贼无聊吗？
|
 |
69
wdwwtzy 2023-02-14 12:17:48 +08:00
楼上很多人说的对，这两种人其实在公司从 0 到 100 的过程中都是必要的，只是适合不同的阶段
|
 |
70
opengps 2023-02-14 13:05:05 +08:00
A：人（个体）很重要，在乎个人发展，最终落幕往往是，项目不是核心了，人就离开了
B：人（团体）很重要，在乎团队发展，最终落幕往往是，成为投资人之一，捆绑平台发展 |
 |
71
xiahouwei 2023-02-14 13:33:51 +08:00
还是先做 A 吧, 没有 A 的能力, 就想 当 B, 会困难重重的
|
 |
73
Immortan 2023-02-14 14:41:07 +08:00
推荐一篇文章叫"Being glue". B 其实就是不可多得的 Glue 型员工。
https://noidea.dog/glue |
 |
74
yuedun 2023-02-14 15:07:29 +08:00
10 楼说的也算是正中要害了。
企业发展过程中一般 A ，B 两种人都会出现。A 属于和公司从 0 开始，他可能就是第一个技术员工，后来陆陆续续招一些人进来，但是他或多或少还是在写代码。假如他不写代码了，也像 B 一样整流程，规范，沟通，大家会觉得都这么忙，你天天整这些不是给人添乱吗？ 反观 B ，他是空降 CTO ，对项目不了解，只能从流程，规范等方面下手，要做些就必须大量招人，找自己人。对于经历过 A 和 B 的下属自然能感受到工作轻松了，但是更多的人是变得不重要了，随时可替换了，如果你不仅没升职还给你安排个领导，你还会感谢 B 吗？ |
 |
75
charlie21 2023-02-14 15:23:31 +08:00
10L: 等 B 把你开了你还说他好么?
however 如果没有管理型 CTO 在增加技术人员话语权 + 创造岗位，你没机会进入这个公司，你也没机会被开除。 在 A 当 CTO 的时候（ A 是否有可能就是这样的人? v2ex.com/t/901873?p=1 ），你倒是想被开除 ... 但有可能你根本进不去 |
|
76
charlie21 2023-02-14 15:33:43 +08:00
在成年人的世界里，金钱可以隐藏很多问题。只要涉及是否动到了自己的钱、是否被开除，那么一个人会立刻警惕起来
人们可以为了钱而忍受很多东西，人们最终唯一无法忍受的 就是没钱 / 被开除。 但这样的人们是否还有对于 “什么是好” 的发言权？ eg 只要我被开除，那么 A 再好，对我而言也是垃圾；只要我被开除，那么 B 再好，对我而言也是垃圾。 只要我被开除，这个地球对我而言就是一颗垃圾星球！ 将被开除的命运怪罪给任何人，都可以，玩可以幻想被 B 开除，我也可以幻想被 A 开除。但最终是我自己的命运，最终我负责 —— 简言之，我根本没有评判好与坏的能力！谁不开除我，谁就是好。持有如此简单的评价标准吗 ...... 那还说什么呢？这是我的故意啊 这是我的自由啊 哈哈哈 |
 |
77
dadaslele 2023-02-14 15:40:33 +08:00
技术管理三板斧，分别是：组织调整到位，加强协同效率，激发团队活力。
我所在的组织，有两位 A/B 的角色，B 的能力发挥不出来，A 算是偏自研框架的，真的做的是苦不堪言，组织调整也是一个很大的问题。B 这种角色，遇到就是很好的发展机会，可惜了 B 拿自己的经验去企业应用，都被 A 反对，没用过，可靠吗？后来 B 也就不说啥了。 |
 |
78
yangyaofei 2023-02-14 15:43:26 +08:00 2
A 参与过开源, 肯定 CI/CD 和代码审查什么的都知道, 也知道好, 但是又能怎么样, 没钱没人就干不动这个
B 可能就是沟通更好, 所有在有了一定经济基础的情况下办了这个事儿, A 也会办但是可能会更晚, 因为嘴没 B 好使 |
 |
79
javlib 2023-02-14 16:05:08 +08:00
我觉得也没必要拉踩，如果可能，老板肯定请一个又懂管理，技术又强的 cto 。
而且看你的描述，现阶段这个 cto 能很好满足公司的技术支持，那就达到要求了。 |
 |
80
shellus 2023-02-15 09:41:09 +08:00
在绝大多数情况下，钻研技术深度的人，很难同时是一个擅长社交沟通的人，因为技术需要思考和沉淀，而社交需要广度
本文的热点在于：我们都是沉默寡言的技术人员 A ，文中夸赞的 B 是我们想做到却难以做到的目标 所以这篇文章，就像在说一个勤俭持家的打工男人，和一个做生意赚大钱的男人对比一样，再说严重一点，就像那些煽动婆媳关系的博主一样，不安好心，制造焦虑，创造矛盾 |
|
81
shellus 2023-02-15 10:05:11 +08:00
作为一个基层技术人员，希望成为哪种类型的人，是因人而异的，取决于每个人的个性、职业发展目标以及对工作环境的喜好。对于是否崇拜沉默寡言的技术型 CTO 或者能言善道的管理型 CTO ，也是因人而异的。
对于一些技术人员而言，他们更关注技术的深度和广度，喜欢在技术领域深耕细作，掌握各种技术的细节和原理，并希望在技术上不断提升自己。这类人通常更倾向于崇拜沉默寡言的技术型 CTO ，因为他们更加专注于技术，更能与技术人员沟通和交流。 而对于一些技术人员来说，他们不仅关注技术的深度和广度，还关注如何将技术应用于实际业务中，如何将技术转化为商业价值。这类人更倾向于崇拜能言善道的管理型 CTO ，因为他们更加关注商业和管理，更能与商业和管理人员沟通和交流。 当然，有些技术人员也希望在职业发展中既能够深耕技术，又能够了解商业和管理，这样的人则更倾向于寻找一位既懂技术又懂商业和管理的 CTO ，他们可以帮助技术人员实现职业发展的多元化。 |
 |
82
simazilinVV 2023-02-15 11:00:17 +08:00
创业型的喜欢 A ，公司业务扩展更喜欢 B
|
 |
83
NoDocCat 2023-02-15 11:16:26 +08:00
A 是典型的社区型选手, B 是典型的商业型选手
|
 |
84
nazhenhuiyi294 2023-04-03 14:07:02 +08:00
如果让我选择 leader ，肯定是 B 更好呀，至少沟通起来没有什么障碍，会很舒服。
|
Select Language