前一阵子有位朋友给我发来一篇文章「我承认，我是被我的 CTO 害死的」，我打开一读，文章写得很糟糕。首先立意就有很大的问题，其中大多数观点似是而非，情绪引导的倾向非常强烈，而我的朋友平时是一位非常智慧的人，怎么会转这篇文章给我呢？

cto职业

我说，这篇文章有毒，你不要转。

他说，啊，怎么会，我还觉得写的好呢，因为和我们 CTO 很像。那我再读一遍。

这次阅读，他不再使用大脑直接产生的反馈回路，而是跳出来做为一个冷静的观察者通读了全文，同样发现问题多多。

有本书上写过一个故事，书名记不清了。有一个人很讨厌自己的某个同事，但也不知道为什么讨厌，讨厌需要理由吗？也许吧，总之两个人交流的时候特别容易起冲突。通过不断的自省和回忆，他终于发现这个同事和很多年前打过自己的同学长的很像，「一巴掌引发的血案」，于是潜意识告诉他，离这货远点。因为相貌，他的同事无辜中枪了，这能怪谁呢？

当你对某个场景或逻辑产生了强烈代入感的时候，很容易产生认知偏差。我的朋友在现实生活中也遇到了这篇文章中描述的 CTO 事件，于是产生很强的同理心，或者叫共情，以至于逻辑出现了偏差。现在我们来看看这篇文章写了什么。

文章的源起是这样的：

2年前，我参与的一个电商创业项目被收购，小幅财务自由的同时，我开始转型小天使，开始寻找好的投资项目。天使投资最重要的就是了解行业，了解团队，我萌生了通过应聘技术岗位去了解各个互联网项目的大胆想法。一试不要紧，几乎80%的互联网项目的技术团队都存在问题，而 CTO/技术负责人就是罪魁祸首。

首先，为了投资去互联网公司「卧底」这件事本身就是不道德的，从根上就是有毒的，由此产生的树干和枝桠再雄伟繁复和盘根错节，都是一种虚幻的「结实」。

其次，按照这个恶心逻辑，他去各个公司卧底至少得工作一段时间吧，即使卧了几年时间，充其量也就是几家或十几家公司的数据样本，这么点数据是如何产生「几乎 80% 的互联网项目的技术团队都存在问题，而 CTO/技术负责人就是罪魁祸首」这个结论呢？

常识不应该是没有完美的团队吗？任何团队，或大或小，或多或少，都会存在问题。另外，CTO 招谁惹谁了？不写代码说技术不行，写了代码说不关注产品。从大公司来的说技术僵化，小公司出身又缺乏经验。现在可好，创业失败的锅都扔过来了，锅沿上还刻了金光闪闪四个大字，罪魁祸首。

对不起，这种锅 CTO 不能背！

其实看到这里基本上就没有读下去的必要了，但看到朋友两肋还插着刀，我只好拿出耐心忍着恶心继续读下去。

不说这篇文章编撰出来的案例，那些东西都是不可考证的，直接说文中的结论。

CEO 一般都是营销/市场/产品出身，所以技术相关的一股脑全部推给 CTO 去负责，自己安心做产品或运营。

这恰恰是非常危险的！

看不出哪里危险了。互联网公司很多 CEO 都是技术出身，即便如此，大部分技术相关的问题也是交给公司的 CTO 出处理，如果 CEO 是营销/市场/产品出身，不更应如此么？否则你找个 CTO 干嘛？难道养起来自己去写代码么？如果你担心 CTO 的绩效，定期做 Review 就好了。

他总是很快地推荐自己的朋友/前同事入职，并催促你尽快同意，一段时间后，你发现公司50%的技术都是他的朋友/前同事；

潜规则：裙带关系的形成，不仅能稳固自己的地位，也可以排挤不认可自己技术方案或不同流派风格的技术人员。

人们总是下意识的把「推荐自己的朋友或前同事加入公司」与拉帮结派、办公室政治联系在一起，实际上这根本就是两码事。

我亲眼目睹有人单枪匹马把办公室政治搞的风生水起，人家就是干这个的。也见过有的管理者在引入朋友和前同事之后一视同仁业务优先，人家是来做事的。

产品把新业务策划出来后，到了约定的交付时间，技术团队还没有把产品开发出来。同一个业务，时间的拖延经常达到3次或以上，问他“什么时候能上线？”他的回答一般就是“目前还不行，因为XXXX的技术问题，所以YYYY”，用你听不懂的技术语言来回答你。

潜消息：CTO 对团队的管理，技术方案风险的评估经验异常欠缺，无法正确地估算生产力和效率。

在这个快速变革的互联网时代，我们一直在与变化并肩而行，你没办法阻止变化发生，只能 live with it。很多业务需求方以为某个项目或产品的时间点确定之后就是永恒不变的，他们永远不会记得自己的需求变化了多少次。

产品延期三次以上当然是问题，但解决这个问题的方法不是替换 CTO，而是让技术、产品和业务能够密切配合，快速迭代，不断修正，小步快跑。

遇到 bug 出现，导致公司出现财务或形象损失，他没有第一时间把责任归咎于自己，而是推给下面写这部分代码的程序员或产品经理，认为是他们的技术能力不过关或是产品逻辑设计缺陷。

潜意识：推给产品或下面，CEO 也不好随便骂我，毕竟我是合伙人，算起来也是公司的二把手或三把手，位高权重。

很多人看到这条会说，咦，这有什么问题呢？这条的问题是，无论是哪个团队的问题「导致公司出现财务或形象损失」，团队 Leader 都不应该把责任推给自己的下属员工，其实推卸了没用，无论你是 CTO 也好，几把手也好，团队出现问题，Leader 承担责任，这不管理常识嘛，和 CTO、技术有什么关系？

最后，文章给出的建议是：

CEO 应该尽量逼自己去和各式各样的技术人员沟通，不能太过倚重一个技术人员，留好 CTO 职位 backup 的同时，也增加技术人脉，为开拓新业务或新项目做准备。多和基层技术人员沟通，及时发现技术团队的问题，如果 CTO 真的太过自负，问题颇多，当断则断，不要畏首畏尾。

这一段有什么问题，大家可以在评论里说说。

很多时候我们都会产生认知偏差。最常见的类似这样：我周围的人们都用 XX 手机，那么这个品牌的手机销量一定很好；我以前遇到过这样的事情，文章也描述了这样的事情，那这样的事情就该是常态……等等。

从最直接的反馈回路中跳出来，自省和独立思考，以冷静的旁观者角度重新审视事件本身，会有不一样的收获。至少，你不会去盲目转发朋友圈里那些热点事件啊。