在 1Password 的一份创始人回顾中，团队长到二十人左右，成了一个转折点。
Dave Teare 写道，他和 Roustem Karimov 曾经自己管理团队。但到了这个阶段，两人觉得需要一位全职 CEO，才能继续往前走。他们既希望得到管理上的帮助，也在意产品原来的方向和公司的做事方式能否保留下来。
Dave 想到了 Jeff Shiner。他们在 IBM 工作时认识，后来成了朋友。2012 年，Jeff 加入 1Password，担任 CEO。
这段经历来自 Dave 在 2019 年 11 月 14 日发布的《14 years of growth: the 1Password story》。当天，公司也宣布了与 Accel 的合作。Dave 用当年请来 CEO 的经历，解释团队为什么再次需要外部经验。它是一份带有合作公告背景的创始人回顾，不是旁观者对全部管理过程的调查。
时间再往前推，Dave 与 Roustem 在 2005 年开始了这家公司，2006 年 5 月 19 日发布最早的测试版。最初想解决的是密码和网页表单填写的麻烦。用户反馈来了，他们继续加功能、修问题。
早期那种工作方式很直接：做产品的人看到问题，动手解决。但团队逐渐有了更多人，带领大家本身也成为一份需要持续投入的工作。Dave 的回顾至少说明，他们承认仅靠原有分工，已经不够满足自己想做的事。
这里没有一个适合照抄的人数标准。二十是这个故事里的阶段，不意味着每家公司到二十人都该换 CEO。原文也没有披露一套完整的授权流程，我们不能替他们补出一套制度，再把它包装成成功原因。
对正在带小团队的人，我更想沿着这个故事追问一件具体的事：当你说已经把工作交给别人，对方究竟可以自己决定什么？
下面是一个假设。一个预约软件团队请来负责人，希望他统筹日常开发与支持。创始人仍然关心产品，也会直接收到老客户的消息。如果创始人随时向工程师承诺新功能，而负责人又在维护另一份计划，那么职位虽然交出去了，决定仍会从两个方向进入团队。
在这个假设里，问题未必是大家不够配合。工程师可能同时收到了两份都有效的承诺，不知道以哪份为准。
一种可尝试的交接办法，是先列出几件经常发生的决定，而不是只写一个宽泛头衔。比如，普通问题由谁排优先级，谁能向客户承诺交付日期，哪些会影响所有用户的改变需要共同讨论。每件事写清默认负责人，以及什么情况需要升级处理。
创始人接到老客户需求时，也按同样的约定办理：可以转述原话、补充背景、说明担忧，但新的时间承诺通过约定的负责人形成。否则，团队很快会学会绕过新负责人，重新回到等待创始人决定的方式。
这套建议还需要接受真实工作的检验。可以选择一类范围清楚、容易调整的日常决定，记录它最后由谁作出、为什么又回到创始人那里。回来的原因可能是权限没讲清，也可能是信息没有交全，或者事情已经超出原来约定的范围。三种原因对应三种修正，不能都解释成“对方还不行”。
涉及重大承诺的决定仍然可以保留共同讨论。交接的目标，是让参与者知道什么时候能够独立行动，什么时候需要一起判断。这里描述的是我的分析和假设方法，并非 1Password 已公开证实的内部做法。
Dave 的文章还有一个细节：他曾尝试写一段很有远景感的结尾，后来删掉了，因为那会让人误以为团队从第一天就有完整清晰的路线。
这个删掉的结尾，反而让前面的故事更可信。先把一个问题做成产品，发现原来的分工不够用了，再请更合适的人承担一份工作，这些选择可以是逐步形成的。回头讲述时，没有必要把每一步都修饰成早已算好的布局。
资料：Dave Teare 于 2019 年 11 月 14 日发布的以下两份原文，2026 年 11 月 6 日阅读全文。历史事实按作者回顾归属，预约软件团队为假设案例。
《14 years of growth: the 1Password story》：
https://dteare.medium.com/14-years-of-growth-the-1password-story-fbbf58ebe28b
1Password 官方 Accel 合作公告：
https://1password.com/blog/accel-partnership
