时间投入到内容创作、投资分析、商业策略思考，以及寻找下一个潜在的“同类”节点上。
一次，他偶然在一个小范围的技术创业者线上沙龙里（他极少参加此类活动，那次是为了收集信息），听到另一个创业者抱怨自己的小团队（5人）开发效率低下，一个简单的后台功能做了一个月还没做完，每天开会扯皮，心力交瘁。
那位创业者问贝西克：“贝总，听说您那边也在做技术开发？就您一个人，还得搞内容，怎么兼顾过来的？有没有什么效率工具推荐？”
贝西克沉默了几秒，在聊天框里打字回复：“工具不重要，重要的是协作模式。我们两个人，远程，异步沟通，27天做了一个完整的数据平台V1.0。”
聊天室安静了片刻。然后那位创业者发了一串省略号，接着问：“……多少？两个人？27天？包括需求、设计、开发、测试、上线？”
贝西克：“是。需求、设计、前端、后端、部署、文档。”
“这不可能！”另一位参与者插话，“除非是那种最简单的CRUD（增删改查）后台。稍微复杂点的数据平台，光前后端联调、测试就得两三周。”
贝西克没有争辩，只是说：“我们不开会，不闲聊，所有沟通基于任务和文档。开发人员每天有至少6小时不被打断的深度工作时间。”
“不开会？需求怎么对齐？进度怎么同步？出了问题谁负责？”那位创业者追问。
“任务描述足够清晰，就不需要开会对齐。进度看任务板。问题在任务下评论解决，谁的责任看任务归属和验收标准。”贝西克回答得简洁。
聊天室又是一阵沉默。然后有人发了个表情：“听起来很美好，但像乌托邦。人不是机器，怎么可能完全没沟通成本？而且，这样的团队能有凝聚力吗？人跑了怎么办？”
贝西克：“我们不需要凝聚力，只需要契约精神和对等交换。人跑了，按协议交接，再找一个符合标准的人。知识都在文档和代码里。”
这番对话让小小的线上沙龙炸了锅。有人认为贝西克在吹牛，有人觉得这种模式太冷血、不可持续，但也有一两个人私下小窗贝西克，询问更具体的操作细节，语气中带着困惑，但也有一丝被压抑的好奇
本章未完，请点击下一页继续阅读！