“管理者应该是‘造钟者’，不应是报时人”

“管理者应该是‘造钟者’，不应是报时人” 这句话出自吉姆・柯林斯的《基业长青》.

造钟者-构建完善可持续的系统

造钟者重点关注构建完善可持续的系统，就像制造一个精准运行的时钟一样。

这个系统包括组织架构、工作流程、规章制度等诸多方面。

系统构建完成后，可以持续长久自行运转，而不需要时时刻刻关注。

例如：

企业的人才培养体系，帮助一个企业源源不断为企业产生能解决问题的人才，无论形势如何变化，总能产生合适的解决问题的人。这种机制就像一个精心打造的时钟，长期为企业发展提供动力。

报时人-时时刻刻关注当下

报时人更像信息的传达者，就如同只负责告诉人们现在几点钟一样。他们只对当下问题、情况进行反馈。

一句话形容就是：“只筑坝，不治水。每日忙于救火，但是不关注火源”

因为没有构建完整的系统，系统不能自运行，需要时时关注，投入大量精力，根据实时的情况，进行决策响应。

报时人是一个没有创造性的机械性工作，而且“报时”管理动作时效性低，可以说报完的这一刻，就是失去意义的一刻，（多么像每周的汇报稿）

思考

1、如果你不能培养解决问题的人，那你就要一直自己救火；如果你不建立能培养解决问题的人的机制，你就要一直自己培养员工；如果系统构建的不好，不能流畅的自行运行，就需要大量的报时人来协调，调度。

2、所以当你发现各种流程运转不畅，需要大量人协调、跟进的时候，可能你并不是需要增加更多跟催的”报时人“，而是停下来思考，是不是你的系统构建的有问题。

3、企业用制度管人、用流程管事，而不是用人来管人，人来管事。管理者把自己活成了报时人，是对能力的浪费。所以好的掌舵人只需制定航线，而差的掌舵人时时刻刻把着舵。

说到这里，想到了云原生的关键技术之一：

声明式 API ( Declarative APIs)：

声明式 API 允许用户定义系统的目标状态，而不是具体的实现步骤。用户只需描述希望系统达到的状态，系统会自动根据当前状态和目标状态之间的差异来执行必要的操作，以实现目标状态。

声明式 API 通过定义清晰的目标状态，确保系统在不同环境中能够保持一致的配置和行为。

在声明式 API 中，描述的是目标状态（Goal State）相对命令式 API，描述的是一系列的动作。这一系列动作如果执行顺利，最终目标状态会达到我们的预期状态。

“命令式 API”需要考虑顺序，而且针对不同状态，需要考虑不同的命令，对命令的执行结果也需要判断与考虑，随着命令增加，复杂度急剧上升。

4、每天随时更新时间表的客车站，和每天 8 点准点发车的列车相比，是不是需要额外花费大量精力制定维护时间表、通知员工客户？所以简化流程，使流程清晰标准，比花费时间经历去保障一个复杂流程顺利运转是更好的提效方式？