在成为 Tech Lead 之后我发现时间变得极度不够用，甚至会成为了我焦虑和殚精竭虑的源泉。因为我无法主动的去做我应该（定方向、做定期回顾）做和想做的事情，而总是被动的被他人牵着鼻子走：无穷无尽的决策请求、寻求帮助、会议邀约。
有两个可以解决这个问题的办法可以简单提一嘴：1）首先你应该尽可能的帮助你的团队成长，让他们尽可能的独当一面，你也就自然不会成为单点依赖；2）根据问题的重要程度和紧急程度划分优先级依然奏效，在精力有限的情况下，有些问题可以暂且搁置不用去解决。
今天我想聊的是第三个办法来源于哈佛商业评论的一篇文章：《Management Time: Who"s Got the Monkey》
(资料图片)
猴子在谁那呢
问题
文章从一个再正常不过的场景开始说起：经理与下属 A 在走廊上相遇了，下属 A 向经理发起了求助：“早上好啊，顺便说一句我现在遇到了一个问题，情况是这样的……”；经理也很自然的回答道：“很高兴你告诉了我，我现在有点忙，先让我想想再答复你”。
同样的事件在一天之内发生了三次，B 和 C 也同时向经理发起了求助。经理忙的焦头烂额，直至下班前 A、B、C 都没有得到经理的答复。他们在经理门外等待答复的过程中难免开始质疑起经理的能力，因为他现在成为了多数人工作的瓶颈。
第二天刚好是周六，经理为了避免下周继续阻塞其他人的工作决定周末去公司加班，在开车经过公司附近的一片高尔夫球场时，你猜他看到了哪三位熟悉的身影？
“到底谁在为谁工作呢？”经理不由得思考起来。
办法
如果我们把问题比喻成猴子的话，从 A 向经理求助的那一刻起，猴子就从 A 的背上跳到了经理的背上，也就是下属的问题成了经理的问题。经理采取了三个手段来解决这个困境。
- 摆脱猴子
在新一周开始的第一天，经理将 A、B、C 依次喊入办公室进行一对一沟通。经理把“猴子”摆在他们的中间，商讨下一步下属能针对问题能够采取些哪些独立行动。在达成一致的同时约定好下次沟通进展的时间。这样下属便又可以继续工作在问题上，猴子得到归还。
- 明确主动性
我们必须要回答的另一个问题是，下属究竟是真的遇到了困难，还是他根本就是想甩锅而已。主动性从低到高可以分为5类：
- 等着被告诉要做什么（主动性最低）
- 主动询问我要做什么
- 建议应该做些什么，并且采取相应行动
- 直接行动起来，并且给出自己的建议
- 独自行动起来，定期进行汇报（主动性最高）
前两类主动性不应该被鼓励，或者直接点说是不被允许的。时间管理的关键在于掌控自己的工作内容和工作时机。（“等着被告诉要做什么”即无法让自己掌控工作内容也无法控制自己的工作时机）。
- 对待猴子（问题）的原则
- 猴子要么被投喂（持续解决）要么被击毙（立即关闭）。等待它自然死亡的过程等无异于无限投入时间却又看不到任何结果，等同于浪费
- 猴子数量应该保持在经理的投喂带宽之下。
- 猴子只应该在约定的时间被投喂（追着猴子投喂，或者允许被随时邀请投喂意味着经理被问题牵着鼻子走）
- 猴子应该通过面对面的方式进行投喂——通过邮件的方式相当于问题又异步的被甩给了经理
- 每只猴子的下一次投喂时间应该被明确下来
作为 Tech Lead 当面对求助时，会惯性的将问题包揽下来。无论这种“我来搞定”的态度无论是出自下意识还是顾虑都不是一个好的实践。不妨把问题当作机会，推他们一把，甚至允许一定范围内的犯错，是让团队成长的一个途径
三类时间
文章把经理时间划分为三类：
- 老板强加给你的时间（Boss-imposed Time）——你必须完成老板交给你的那些任务，否则会得到迅速且直接的惩罚
- 系统强加给你的时间（System-imposed Time）——你必须响应同级别同事的工作诉求
- 自我时间（Self-imposed Time）——做那些你的经理和团队同意你去做的事情。这类时间又可以继续划分为两类
- 下属时间（Subordinate-imposed Time）——用于支援下属的时间
- 自由支配时间（Discretionary Time）——真正属于经理自己的时间
很明显，对于前两者你能够拒绝的空间十分有限。适当的降低下属占用你的时间，也许是更切实有效为自己争取一点自由的方法。
你可能会喜欢
- 去年我是怎么解决团队问题的
- 测试覆盖率治不好你的精神内耗
- 昂贵的质量
- 理解流程
- 帮助团队成长是唯一的出路
- 开源社区的暗面
- 去年做 Tech Leader 犯过最大的错
- 技术写作的困境
- 拥抱原则与面对现实
- 代码与质量的思考与随笔
- 从对 Vue 中 mixin 的批评，到对模块间依赖关系的探讨
关键词：
