第6章 04：不懂代码也能选对CTO#
有一种恐惧让非技术创始人陷入瘫痪：“我不懂技术，怎么评估技术合伙人？“他们说这话的语气像在边境没带护照时的自白。
让我直接说清楚：选CTO不需要懂代码。不需要分清Python和Rust、微服务和单体架构、SQL和NoSQL。你需要的是正确的问题和解读证据的能力。
评估一个你不懂其领域的人，不是技术问题，是判断力问题。而判断力是有方法论的。
行为验证法#
大多数人通过自我评估来评价他人。“你后端开发能力怎么样？““给你的领导力打个分，1到10？““你的优势是什么？”
这毫无价值。关于自我评估偏差的研究（Dunning-Kruger，1999）表明，所有人都会高估自己。自我评估就像一面自带美颜滤镜的镜子——只展示本人想让你看到的东西。
替代方案：行为验证。不要问人们能做什么，问他们做过什么。使用STAR框架——情境（Situation）、任务（Task）、行动（Action）、结果（Result）。
情境。 背景是什么？“讲一个你的团队面临紧急技术截止日期的情况。“你需要具体细节——真实项目、真实公司、真实时间线。模糊的回答（“我们经常有紧迫的截止日期”）是危险信号。真正做过这件事的人记得细节。
任务。 他们的具体职责是什么？不是团队的——是他们个人的。“你个人负责交付什么？“这一步把领导者和搭便车的人区分开。真正的负责人会精确描述自己的范围。搭便车的人会把个人贡献模糊到团队成就里。
行动。 他们实际做了什么？“一步步走我过一遍你的行动。“这是金矿。追问细节。当有人说"我设计了系统架构”，追问：“关键的设计决策是什么？为什么选这个方案而不是其他？接受了什么权衡？“真正做过这件事的人能深入三四个层次。没做过的人在第一个层次之后就会变得含糊或防御。
结果。 发生了什么？“结果是什么？你怎么衡量成功？“具体结果很重要。“系统承受了10倍的流量"有用。“进展顺利"没用。还有关键的追问：“如果重来，你会怎么做不同？“真正负责结果的人思考过这个问题。没有的人会给你一句排练好的话，比如"加强沟通”。
STAR方法有效，因为行为是预测未来行为的最佳指标——不是学历，不是自我评估，不是推荐信。一个人在特定情境下、真实压力中、有真实利害关系时做了什么——那才是你的数据。
输出验证：信任但核实#
行为面试揭示一个人的思维方式。但你还需要验证他们的实际输出——即使你自己无法评估。
三种方法，按可靠性排序：
看他们的作品。 要求看他们做过的东西——开源贡献、业余项目、已上线的产品。你不需要看懂代码，你需要看到代码存在，他们能指向自己创造的具体成果。一个没有任何公开作品的CTO候选人不是自动出局，但这是一个数据缺口，必须通过其他方式填补。
找第三方评估。 找一个你信任的技术人士，让他们审查候选人的作品。朋友、顾问，或者花两小时费用请的咨询师。给他们一个明确的问题：“根据这些代码/产品/架构，你会信任这个人在创业公司领导技术团队吗？“一个称职的评估者一个下午就能给你清晰的信号。
做一个付费试用项目。 在确定联合创始人关系之前，一起做一个小型、有明确范围的项目——两周，清晰的交付物。这是你能得到的最好数据。你能看到他们如何沟通、如何应对模糊性、如何做权衡，以及他们实际产出什么。一个糟糕的CTO招聘成本是数月。两周的试用成本是两周。
行为面试加上输出验证，给你一个坚实的判断基础——即使在你不懂的领域。
价值观对齐检查#
技术能力是必要条件，但不充分。CTO关系崩盘的最常见原因不是能力——是价值观不匹配。
三个维度的错位足以致命：
速度 vs. 质量。 你想六周内发布MVP。你的CTO想要一个"正经"的架构，需要六个月。双方都没错——但在创业公司，速度几乎总是赢家。如果你的CTO无法忍受发布不完美的东西，你会烧光预算去建一座没人来的大教堂。
测试方法：问他们有没有发布过自己不引以为豪的东西。如果想不出来，或者故事里充满了关于为什么坚持质量的辩护——谨慎推进。
自主 vs. 指导。 有些技术领导者需要清晰的规格和明确的任务。另一些人想要拥有问题空间，自己找出解决方案。在创业公司，你需要第二种。问：“如果我给你一个问题但没有规格说明，你会怎么做？“正确的答案涉及跟用户交流和做决定。错误的答案涉及找你要文档。
长期 vs. 短期。 有些人为下个季度优化，有些人为未来五年优化。创业公司需要能在两者之间切换的人——为今天而建，为明天而设计。纯短期思维产生技术债，在第二年杀死你。纯长期思维在第一年什么可用的东西都产出不了。如果他们在任一方向上有僵化的哲学，他们会在创业公司要求的持续上下文切换中挣扎。
跨领域评估的陷阱#
即使方法扎实，跨领域评估也有坑。
自信偏差。 自信的人听起来很有能力，特别是在你不懂的领域。一个权威地谈论"可扩展分布式系统"和"事件驱动架构"的CTO候选人，对非技术创始人来说可能听起来像天才——即使他们只是在串术语。对策是始终追问具体细节。自信的概括很廉价。关于真实项目中真实决策的具体细节——那些很难伪造。
光环效应。 简历上的大公司名字会产生令人盲目的光环。“她在谷歌工作了五年"几乎告诉你不了她个人成就了什么、她如何应对创业混乱、她能否从零开始建设。谷歌有18万员工。有些人很杰出。有些人是在一个杰出系统里的普通人。简历告诉你的是一个人在哪里工作过，不是做了什么。
技术恐吓陷阱。 有些候选人故意使用行话制造信息不对称。如果你不理解某些内容，让他们用大白话解释。如果他们做不到——或不愿意——这就是一个信号。最好的技术领导者能把复杂概念解释得很简单。平庸的人躲在复杂性后面。
“以后再学"陷阱。 你告诉自己，总有一天会懂够多的技术来正确评估你的CTO。你不会的——不是因为你不够聪明，而是因为你有一百件其他事要做。在做决策的现在就建立你的评估体系。不要把验证工作推迟到某个你以为会有更多时间的虚构未来。
团队审计#
以下是你的练习——适用于每个关键团队成员，不只是CTO。
选一个你不深入了解其领域的团队成员。你的市场总监、首席设计师、销售负责人。对他们加入以来的表现用STAR方法审查。
拿他们最重要的项目：
- 情境： 他们开始时的背景是什么？
- 任务： 他们具体负责什么？
- 行动： 他们个人做了什么？（不是团队做了什么。）
- 结果： 可衡量的成果是什么？
把他们的行动和他们声称的能力对比。匹配吗？他们说能做的和实际做过的之间有差距吗？
如果发现不匹配——一个谈"领导"但行动显示"参与"的人，一个声称"战略思维"但结果显示"战术执行"的人——你有一个校准问题。你一直在用关于团队真实能力的不准确数据运营。
对每个关键角色都做这个检查。花一个下午。它产生的清晰度值数周的猜测。
你不需要成为技术专家才能领导技术团队。你不需要成为营销专家才能评估你的市场总监。你需要的是一套从真实行为中提取真实证据的方法——以及即使答案令人不舒服也坚持使用它的纪律。
方法是现成的。问题是你会用它，还是继续依赖直觉和亮眼的简历。
直觉有它的用处。但它不该成为你做出最重要招聘决策时的主要工具。