产品工程对齐系统

入职前就该做的评估

• 把"是否有好的工程搭档"列为接不接 offer 的评估标准——有好想法但建不出来，等于零。要么确认搭档靠谱，要么确认组织愿意换人。

防"问爸又问妈"的规则

• 明确分工：哪些他驱动、哪些你驱动，模糊地带当场商定归属。
• 绝不允许绕行：有人拿工程域的问题来找你，回一句"你和 Cal 聊过吗？"——组织里的人会试探两位家长要不同答案，这个口子不能开。
• 底层是相互信任 + 说到做到："需要更多移动端工程师，否则 X 发不了" → "我来处理"，就此结束；有问题他会主动回来找你。

联合评审机制（可直接抄的形式）

1. 所有评审一起出席：OKR 评审、周会从不单独开，各自主问自己领域，但始终同框。
2. 异步 OKR 评审：团队多到开不完会后改为——每团队一个规划频道，发 doc + 限时视频讲重点；两人（各带一名 chief of staff）集中马拉松式看完，把 follow-up 问题贴回频道，只对 5-10 个高优/多疑问团队补开会议。改革动因：某季度盘点发现 OKR 评审总耗时 300+ 小时。
3. 周一顶级 OKR 会：红黄绿标记，绿的不讲，只讨论红的和问题项。
4. 每周四人会：两位负责人 + 两位 chief of staff 过组织问题，必要时请当事负责人（如 QA）进来讲。
5. 流程本身按季度迭代：像迭代产品一样迭代管理流程，每季度问"这套 OKR 规划行不行"，不行就改。