面向奥地利初创公司的兼职 CTO 30/60/90 天计划

您已经聘请了一位兼职 CTO。前 90 天究竟应当产出什么？第 0 到 30 天是评估与稳定：一轮倾听、跟随真实工作、风险分诊，并且只做低风险的快速见效项，最终交出一份书面的工程现状评估。第 31 到 60 天是规划与打基础：一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标，并修复排名前一到两位的风险。第 61 到 90 天是执行并做好交接准备：通过新节奏交付一项成果，用风险和投资的语言向董事会汇报，并把组织调整到无需 CTO 每天在场也能运转。兼职 CTO 的价值不在于成为屋子里技术最聪明的人。它在于一套交付物和一个仍在运转的系统，能在他离开之后留存下来。

这是执行计划。关于究竟要不要聘请，以及成本如何，请参阅何时在奥地利聘请兼职 CTO以及日费拆解。本文回答下一个问题：现在人已经在公司里了，接下来会发生什么。

塑造这 90 天的那条原则

一位新任技术负责人能犯的最大错误，就是在还没有可用替代方案之前，就拆毁现有的执行体系。一家能交付的初创公司，哪怕做得乱糟糟，也比一家在重组中途被冻结的公司更有价值。因此这个计划把理解前置、把变革后置。第一个月主要是倾听；真正的变革，只有在负责人真正理解了这地方如何运转之后才开始。

第 0 到 30 天：评估与稳定

这里的模式是海绵，而不是推土机。与每个人一对一交谈（在少于 30 人的团队里，就是字面意义上的每个人），并问两个问题：你会改什么，以及什么东西运转得太好、我们绝不能弄坏。跟随真实工作：坐下来看支持工单，观察一次事故，并亲自交付一处微小改动以感受部署流水线。同时进行一轮风险分诊，它会成为第一份交付物：安全、单点故障、关键人物与公交因素风险、基础设施成本以及交付瓶颈。只采纳低风险且可逆的快速见效项，那种能赢得信任而不押上公司的项。

一位优秀的兼职 CTO 在第一个月里会刻意不做的事：不重写、不重组、不大改流程、不裁员，唯一的例外是真实的安全或安全隐患威胁。在第二周就提议从零重写的人，向您展示的是一个危险信号，而不是领导力。

第 31 到 60 天：规划与打基础

现在变革开始了，但要以有边界的实验进行，而不是一次性大爆发。最多推进一到两项限定时长的改动，以免团队不堪重负。产出经过优先级排序的技术路线图，把工程工作与资金跑道和产品目标绑在一起。如果需要招聘，就为最多几个关键岗位写一份聚焦的计划，因为招聘每个岗位都有固定开销，十个空缺职位本身就是一种失败。建立交付节奏：冲刺、站会、代码评审，以及清晰的完成定义。搭建起基础工程指标（四项 DORA 指标是惯常的起点）。并修复风险清单中排名前一到两位的风险，过程中把架构与供应商决策记录为 decision records。

第 61 到 90 天：执行并做好交接准备

通过新节奏交付一项真实成果，让变革得到证明，而不只是被宣布。建立一份对创始人或董事会的定期汇报，用董事会真正会思考的两种货币说话：风险和投资，而不是故事点。最终敲定 decision records 和 runbook。并做好那件定义兼职合作的事：把组织调整到无需 CTO 每天在场也能运转。第 90 天有一个有用的自测：你能否说出团队中每个人各自的独特之处；如果不能，说明你没有进行过正确的对话。最后，把成功指标以及那个会告诉你"该聘请全职 CTO 了"的触发条件写下来。

一位优秀的兼职 CTO 留下的交付物

这就是真正的合作与昂贵的 Slack 存在感之间的区别。要把这些都要到手。

一位给您留下一支能运转的团队和这些文档的兼职 CTO，算是把工作做完了。只给您留下感觉和一段聊天记录的，则没有。

如何衡量他们，以及反指标

用四项 DORA 指标衡量交付的可预测性（部署频率、变更前置时间、变更失败率，以及服务恢复时间）、从清单中关闭的风险数量、把团队速度和士气作为趋势而非绝对值来看、对照计划完成的招聘岗位，以及最被低估的一项：创始人腾出了多少时间，因为创始人不再是每一个技术决策的升级路径。

不要衡量代码行数。它奖励数量而非价值，而删代码往往才是胜利。那位在一份生产力表格上填报"负 2,000 行代码"的 Lisa 工程师，把软件做得更快更小，他做得完全正确。并且要警惕那种计划是从零重写的 CTO；把能用的软件从零重写是经典的战略错误之一，因为读代码比写代码更难，而旧代码承载着多年来已修复的 bug。

"聘请一位兼职 CTO，是为了让他按计划把自己变得不再被需要。交付物不是他出现在会议里。而是一支没有他也能交付的团队，以及那几份文档，让下一个人能从他停下的地方接着干。"

何时用全职聘用替换兼职 CTO

触发点是工程管理本身变成一份全职工作的时候。实际上，那大致是一个人再也无法把团队维持在健康管理幅度内的那个点，大约是八名或以上工程师的标线，以及有人每周超过一半的时间花在管理而非构建上的时候。再加上已越过 product-market fit、需要持续的每日执行，这就是把这个角色引入公司内部的信号。成本和时机我们在何时在奥地利聘请兼职 CTO中有讲，所以这里的重点是交接，而不是算账。

把过渡当作缓慢的接力，而不是一刀两断。兼职 CTO 为自己的接替者撰写职位描述并甄选候选人，主持结构化的知识转移，并在交接系统的同时交接关于人的知识。这正是交付物发挥作用的地方：decision records、路线图和 runbook 就是交接包。新上任的全职 CTO 从第一天起就对决策负责，而兼职者退到顾问角色或彻底退出。

奥地利视角

这种合作几乎总是企业对企业的固定聘约，而非雇佣，形式上是 freier Dienstvertrag（持续提供服务的自雇式服务合同）或普通的自雇合同以提供持续可用性，或在有单一具体交付物时采用 Werkvertrag（成果合同）。这使其免于工资税和雇佣义务，但必须构建得当以避免假自雇（Scheinselbstständigkeit），从而让 CTO 真正自行决定其时间和方式。资深工程师市场很紧俏，尤其在维也纳以外，填补一个资深岗位可能要花好几个月，这也是为什么一位同时还擅长招聘的负责人很有价值。一位优秀的负责人懂得资助版图：aws 的项目资助公司建设以及种子或成长期融资，而 FFG 资助真正的研究与开发。因此路线图及其文档应当构建得当，使研发工作能干净地映射到 FFG，而公司建设映射到 aws。这是一个具体的、桌面上真金白银的理由，说明文档纪律在这里为何重要。

兼职、临时、全职，还是联合创始人？

对于执行阶段，真正重要的区别很简单：临时是全职但有期限，兼职是非全职但持续。

对于处于或刚好在 product-market fit 之前的早期初创公司，兼职 CTO 搭建可运转的系统；临时者补一个窟窿；而全职或联合创始人回答的是关于持久性和所有权的另一个问题。

我们的兼职 CTO 服务正是按上面这 90 天来执行，采用按周可取消的 retainer，投入的是两位创始人而不是一名外包。如果你缺的人更接近合伙人而非雇员，兼职联合创始人这种形式回答的才是所有权问题。兼职 CTO 与临时 CTO 对比把两者并排放在一起，而 Polity 展示了合作结束后仍然留存下来的交付体系。