核心定位
CTO 并非单纯的技术专家角色，而是技术与商业的翻译者、团队效能的放大器。本规则集围绕 "技术服务于商业目标" 这一核心原则，构建了覆盖战略、执行、团队、文化的完整 leadership 框架。
核心用法
技术战略层面：建立"买还是造"的决策标准——仅自建核心差异化能力，其余采购；主张"单体重构优先于微服务"，避免过早分布式的成本陷阱；要求技术路线图与商业路线图绑定，用业务语言解释技术投入。
架构决策层面：强制 ADR（架构决策记录）机制，确保决策可回溯；强调"可逆性优先"，偏好能撤销的选择；关键路径采用"无聊技术"，隔离创新风险。
技术债务管理：将债务重新定义——非偶然的混乱，而是有意识的权衡。要求显性追踪（backlog 而非心理笔记），建议 20% 时间持续偿还，反对纯重构冲刺。
团队建设：提出 "斜率 > 截距" 招聘哲学—— junior 岗看重成长速率而非当前技能；Senior 岗评估团队产出放大效应；强调内部晋升对文化的保护作用。
规模化原则：5-8 人小团队+清晰所有权；警惕沟通复杂度 O(n²) 增长；推行书面文化替代会议文化。
显著优点
- 实战导向：每一条规则都包含具体的执行方式（如"20% 维护时间"、"ADR 文档"），非空洞理念
- 权衡意识：明确承认"有些债务是可接受的""过早优化有害"，避免绝对化
- 反模式识别：专设"常见错误"章节，直击 CTO 典型陷阱（过早平台化、重写冲动等）
- 度量体系：引入 DORA 指标、周期时间追踪等工程管理工具
局限性与适用边界
- 规模假设：默认语境为成长型公司（startup→scale-up），对成熟大企业（500+ 工程师）的矩阵管理、跨 BU 治理涉及有限
- 行业盲区：未区分 B2B SaaS、 marketplace、基础设施等差异场景的具体策略
- 地域文化："快速解雇价值观不合者"等建议需适配当地劳动法规与文化语境
- 技术栈中立：过于泛化，缺乏云原生、AI/ML 等特定领域的技术决策指引
适合人群
- 首次担任 CTO 的技术联创（提供系统 checklist）
- 从 IC 转型管理的 VP Engineering / Head of Engineering
- 投资人评估被投企业技术健康度的参考框架
- 技术总监准备晋升的自学材料
潜在风险
- 教条执行："单体重构优先"在特定场景（强监管多租户需求）可能不适用
- 度量反噬：DORA 指标若与绩效考核挂钩，可能诱发数据操纵
- 文化冲突："书面文化优于会议"在关系型商业环境中可能遭遇阻力
- 技术疏离："偶尔写代码"的建议若执行不当，可能导致技术判断力衰退