这几天看 Andrew Wilkinson 的一些文字、访谈，颇有收获。比如有一篇Lazy Leadership（https://medium.com/flow/lazy-leadership-8ba19e34f959），我记录一些觉得有点意思的内容。

懒惰其实是退后一步，依靠你的团队。成为一个观察者，而非业务的积极参与者。在这个过程中，授权很重要，这是一个持续、逐步地将自己从工作中摘除，并授权团队，让他们做最擅长的事的过程。

作为 CEO，你的工作是制定战略和文化、授权和激励（言外之意是，别干那么多具体的工作了）。

CEO 是个人类路由器——将机会和人才向公司输入。企业家的目标应该是，自己不做具体工作，专心为团队中合适的人提供机会。建立一个系统，让自己成为一个人类路由器。我在工作中感到压力，往往是因为我没有建立这个系统，导致有一些我无法委派、授权出去的任务。

问自己：如果你去度假六个月，公司会发生什么？如果你认为它会分崩离析，那么你可能处于授权不足、沉迷细节的状态。

创业初期，我是设计师、HR 和销售——我擅长这三件事，但同时我也做财务、项目管理等我不擅长的事。公司混乱、效率低下，我们的客户不愉快。今天，我只把时间花在我既擅长又没人能做的事情上。

我在公司做的一件重要的运营工作，是了解我们的客户，并确保我们满足他们的需求。了解客户并建立信任是关键，这样我才能制造一台能够解决他们的问题，达成他们的目标，交付出色工作的机器。

考虑到可能发生的意外导致我不能工作，我在每个关键岗位上都聘请了比我更优秀的超级人才，这样我可以专注重要的事情：我们的文化、流程和结果。

找到合格的管理者后，你就不会再担心他们的业务。

对于拿着锤子的管理者，一切都像钉子。销售经理说，我们将通过销售实现目标。营销经理说，我们将通过营销实现目标。产品经理说：我们将优化产品实现目标。财务经理说，我们通过财务方式实现目标。真正的魔法发生在，有一个管理者代表这四种方向（不偏执，能找出最好的路径）。

成长中好的部分，是你可以委派你不喜欢的事情。成长中糟糕的部分，是你通常最终会委派一些你喜欢的东西（自己却不一定能做）。

• 火星救援 08.09
• 简单法则：设计、商业、生活的完美融合 08.10
• 简约至上：交互式设计四策略 08.15
• 三双鞋 08.21
• 沃伦.巴菲特的 CEO 们 08.28

8 月好书推荐：

• 火星救援 - 多次绝境又找到出路的峰回路转，虽然是本“爽文”式的科幻小说，但还是尽量认真地给出科学依据。

近日看新闻，有城市的健康码，在红黄绿之外，增加了橙码。我有些小感触——各城市健康码的产品经理，段位可以看出明显差异。

就橙码这个创新而言，平白给产品增加了一种状态——红黄绿，与交通灯一致，深入人心，而新增元素，各地使用方法不易统一，增加研发和宣传成本，某种程度上还会导致用户误解，这个实体加得没必要。

但有城市的健康码，高明得多，非常聪明地重用了消息通知功能，根据条件，给不同用户推送通知。例如可以对来自高中风险地区用户、疑似密接用户、境外用户，根据条件，给不同的弹窗提示（同时因为有弹窗，可以遮挡健康码——这时无法查询绿码，也属合理）。这种设计，达到赋红码效果的同时，体感上柔和得多。而且通知功能，还能扎扎实实地用在引导行动上，例如，可以分批次要求民众进行全民核酸。

这是我看到的一反一正两种健康码设计，更简洁的胜出。如非必要，勿增实体。这个原则还是有道理的。

还想起另一件小事：

同事想解决某个问题，需要在公司上新的 SaaS 软件，以实现一个并非高频使用的功能。我跟他讨论时表达了我的观点：

我曾经在多家企业内部推动过不同的新业务系统——比如任务管理、知识管理、内部社区、文件共享、Wiki……绝大多数都是失败的，只要非高频，就总得反复提醒，直至最终放弃。

所以我提的问题是：有没有其他方案能达到目的，又不需要新增系统？比如，是不是可以直接用微信群，或者云文档来满足需求？

这也是我希望的如非必要，勿增实体。当然，最后决定还是他做。

今天看到一句据说是比尔盖茨说过的话，挺有道理的，或许也是另一个角度的如非必要，勿增实体吧，都是尽量让事情更简单一些。

“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”

这两周有点特殊情况，上周公众号周更食言，回头再补。

今天推荐《简约至上：交互设计四策略》。我多年前初学产品，看过这本书，很合胃口，向不少好朋友推荐过。最近重读，还是很有收获，这本简单的小书，把怎么做到简单，写得很清晰。

本书结构，头两章，写什么是简单、为什么要简单、有共同的愿景能更好地实现简单。第三章开始引入达成简单的四种方法，并用四章逐一描述。第八章收尾，说明复杂的顽固、简单的艰难、共识的重要，以及要以用户为中心。

达成简单的四种方法分别是：删除、组织、隐藏、转移。

删除最好理解（实际上也最难，很多时候，设计者不敢删——比如：你敢拒绝老板提出来的需求吗？），删掉一切能删的。完美并非加无可加，而是减无可减。

组织可以理解为按照一定的规律，抽象、分组。有时候，可以用一个特性，解决一百个需求——前提是你能将那一百个需求抽象出来。

隐藏则是把不重要的、非核心的部分收到更低一级的位置，免得造成干扰（如果需要隐藏，可以再想想，是不是索性删除了？）。

转移——这个我理解起来有些困难，作者举的第一个例子是遥控器——有些遥控器的简化，是将复杂的功能挪到电视 App 中，遥控器仅仅是个选择、确认工具。作者举了另一个例子是旅行规划软件，去除目录的名称约束，实质上是转移给了用户，让用户琢磨名称而非在几个固定名称中选择。

转移我一直理解不好，尝试套用知识星球的例子，或许可以理解为：创业团队营销能力有限，因此尽力提供“好工具”，提供“运营辅助”，而主要的运营工作，是转移给了星主。也正因为如此，我们只能收取工具应拿的费用。

乔布斯提到过：乍一看到某个问题，你会觉得很简单，其实你并没有理解其复杂性。当你把问题搞清楚之后，又会发现真的很复杂，于是你就拿出一套复杂的方案来。实际上，你的工作只做了一半，大多数人也都会到此为止……但是，真正伟大的人还会继续向前，直至找到问题的关键和深层次原因，然后再拿出一个优雅的、堪称完美的有效方案。

这或许也是“看山是山，看山不是山，看山还是山”的一种解释。

无论你是不是产品设计者，这本书都值得阅读。

我第一次听说 OKR 时，觉得只是类似 KPI 的绩效管理工具。看了几本书后，觉得应该适合我们，两年前尝试在公司内推进，效果不好。最大的原因在我身上——执行不力。

今年再推 OKR，我重读了相关书籍，并且请 HR 同事督促着开会、1V1 沟通，目前看，能正常推进，效果暂时还不显著（比如：季度的 O 一直没达到、KR 的拆解总觉得不到位），还是打算继续做，长期做。

目前看，至少我们执行过程中还存在一些问题。比如目标并未全员沟通，有很多同事实际上不了解公司的年度、季度目标。比如我的执行力不够，1V1 沟通有时没能及时进行。目前都考虑了改进计划。

以下我从书中学到的一些 OKR 知识、规则，做个简要汇总。

OKR 希望达成的目标

OKR 建立在"洞察"对基础上，反映责任人对业务的思考，OKR 的质量，反映制订者的思考与洞察的质量。

执行 OKR，希望达成以下目标：

聚焦：让同事们都清晰地知道目标是什么，朝一个方向努力

透明：公司内部尽可能信息公开，让大家拥有做决策需要的资源

协作：在成员彼此信任的前提下，有机会紧密沟通与协作

挑战：做到自己能达到的最好

OKR 的基本规则

执行周期：年度 + 季度，公司按年度设计，部门和个人按季度设计

OKR 的实施的四件事

制订：各自草拟，周期开始前的 1-2 周

对齐：负责人和员工对齐 OKR 并确认优先级，周期开始后的 1-2 周

进度追踪：定期复盘、根据业务需要调整

打分与评定：用户自评、团队复盘

注意

结果自评，与绩效、奖金无关，不做考核，鼓励大家创建有野心的目标

如果发现需要调整，在进行周期内也可以修改

目标（O）不超过 5 个，每个 O 对应的 KR 应该在 2-5 个

每月回顾 OKR 进展，每季度对 OKR 集体开会讨论

目标（O）的制订

找到这个周期内最具价值，最需要投入精力的目标。

O：我想完成什么（What + Why）

好目标的特征

一般为定性描述（定量可能反而带来心理压力、带来限制，如果不担心这些问题也可以定量）

明确行动方向（少用协助、帮助、参与、支持这样的词）

责任范围可控（自己能控制至少 70%）