有读者反馈让我多谈谈“领导力”，这真是一个勉为其难的任务。我和大多数人一样，都不是“真正准备好了”才走上领导岗位的，所以谈起“领导力”不会有宏伟框架和细致理论，只能结合自己的经验来讲解。今天我想讲讲和领导力有关的 3 点经验，或者说走上领导岗位的 3 点注意事项。
第一，身为领导者，你需要留出固定的时间考虑“不紧急但重要”的事情。
按照“重要”和“紧急”两个维度来划分工作的办法，很多人都会，而且大都知道要怎么做：优先做“紧急而重要”的事情，然后根据具体情况选择“不紧急但重要”或者“紧急但不重要”的事情，对“不紧急而不重要”的事情基本可以不理。
道理很简单，但真正做起来往往只看到了“紧急”而忽略了“重要”——“紧急而重要”和“紧急而不重要”的事情往往占据了我们大量的时间，“不紧急而重要”的事情就被无视了。
这大概和人的天性有关，我们每个人心里都有个“时间窗口”，我们只关心这个时间窗口里的问题。只有肚子饿的时候，吃饭才进入了时间窗口。只有周五的下午，写周报才进入了时间窗口。对于没有进入自己时间窗口的问题，我们或者是认为“现在不需要去关心”，或者干脆认为是“杞人忧天”。
对普通人来说这么做是没有问题的，但对于领导者来说这么做就不可行。“二爷鉴书”的作者二爷说过一句很有名的话，“好的产品经理最重要的素质是让正确的事情相继发生”，对好的领导者来说，这个素质同样重要。
那么，如何让正确的事情相继发生呢？尤其是在大多数人的时间窗口有限，只局限于“紧急”事情的情况下？很显然，领导者应当适时把事情推进大家的时间窗口，让“不紧急但重要”的事情在合适的时间变成“紧急而重要”的事情。要做到这一点，领导者就必须留出固定的时间来考虑“重要但不紧急”的事情。
理解这一点就会明白很多事情。同样是工作报告，对基层员工的要求往往是日报和周报，对领导者的要求则是月报、季报、年报。为什么？因为显然每天、每周的工作都是“紧急”的。但是一年 365 天，52 周能不能持续完成“紧急”的任务，这些任务组合起来是不是“不紧急但重要”的任务，或者是否有“不紧急但重要”的任务被遗漏，错过了“重要而且紧急”的时间节点？这些问题的答案，能充分反映出团队有没有领导这，领导者能力高低的差别。如果领导者能时刻记得“不紧急但重要”的任务，适时把它们推入团队的时间窗口，表现多半不会差。
如何留出足够的时间考虑“不紧急但重要”的事情呢？我的经验有两点：第一，在制定目标的时候深思熟虑，确保你的季度目标、年度目标、战略目标是合理的稳定的，并清楚地写下来；第二，时常抽时间回顾这些目标，时常把自己手头的工作与这些目标联系起来，然后就会有很多新的想法。
第二，身为领导者，如果某项工作在你的职权范围内能找到资源去完成，就应当尽量避免自己做。
我曾经写过《技术领导要不要写代码》，这个问题困扰过我很久，而且据我所知它还困扰过很多技术领导者，更诡异的是，一些不会写代码的人同样是优秀的技术领导者。推而广之，除去明显错位的“外行领导内行”，确实有不少“非专业”的优秀领导者。那么，专业技能到底重要吗，有多重要？
后来我逐渐明白了，这个问题可以换个角度来看：领导者是否具有足够的资源来完成他所要完成的任务。如果从资源的角度来看，即便是技术项目，需要的也不仅仅是“写代码能力”这一种资源，还需要时间、金钱、服务器等等资源，以及表达能力、组织能力、协调能力等等资源。这时候单打一是无论如何行不通的，你的技术做得再好，如果没本事否定产品设计上的无理差劲需求，整个项目就不可能成功。
可惜的是，这样的局面不少技术出身的领导者并不能妥善的应对，他们往往更愿意埋头写代码给予自己安全感，而较少愿意勇敢直面真正的挑战。结果往往是项目搞砸，自己拿不到好的绩效，团队士气也很低落。
如果从资源的角度来看呢？除去写代码能力这一种资源，我们还需要时间、金钱、服务器、表达能力、组织能力、协调能力等等各种资源。写代码能力这种资源对我们来讲，是不是已经满足甚至过剩了？如果是，领导者就应当充分放手让团队成员去写代码。而表达能力和协调能力两种资源是否非常稀缺？如果是，领导者就应当着力补充表达能力和协调能力，或者自己锻炼成长来应付，或者招募合适的人才来应对。但是退一万步说，哪怕领导者自己写代码再牛再爽，也应当克制住自己写代码的冲动。
第三，领导者一定要注意克制自己的个人偏好。
有一次，我和我的领导讨论为团队选择编程语言，我给出了自己的答案和若干理由，而且自信自己能驾驭得了这种选择带来的各种工程问题。但是这个答案被否定了，原因是它并不适合团队的现状，尤其是团队未来的发展，以及对人才的吸引。末了我的领导说“这种问题一定要通盘考虑，有一门编程语言我自己最喜欢，但我绝对不会拿出来作为团队的选择，因为不合适。” 这个说法给我的印象太深刻了，因为它清晰地区分了“我喜欢”和“团队适用”，强调必须从团队的角度来思考和决策。
不知道是不是中了乔布斯的魔，很多领导者潜意识里或多或少地认为自己是对的，总有一点“世人皆醉我独醒”的希冀。所以面对很多问题时总要认定自己是权威，自己的意见最有道理，哪怕其他人有一万种反驳意见也不在话下。
但是如果我们仔细读过乔布斯的传记，再读过读过伟大企业家的传记就会发现，乔布斯的成功方式并不适合普通人。对正常的企业来说，那种偏执狂式的、很多时候依靠直觉而不是数据的思考和决策方式，其实是成功概率相当低的选择。要想提高成功概率，就应当回到常识，讲求数据和逻辑，讲求客观。
很可惜，基本没有人能做到完全客观、严格遵循数据和逻辑，人的选择总会带有自己的偏好，尤其是在没有数据支持、又缺乏天赋和训练的情况下，这种个人偏好的色彩可能更加浓重。如果仅仅是个人选择的依据当然没有问题，但作为团队的选择就应当慎之又慎。
拿我自己来说，我比较喜欢静态语言，尤其是语法规整的静态语言，哪怕繁复一点都无所谓；我比较喜欢严谨清晰的逻辑，不喜欢“揉成一团”的代码；我比较喜欢轻量级的框架；我比较喜欢思维敏捷、表达清晰、性格活泼的开发人员…… 总的来说，我有一系列的偏好，虽然我甚至说不清楚每种偏好的理由。
但是我明白这都是我个人的偏爱，未必应当成为团队的选择标准，所以我来组织团队，绝对不会简单拒斥灵活的动态语言，不会简单拒斥重量级的框架，也不会简单拒斥思维不那么敏捷、性格不那么活泼的开发人员……
因为我很清楚，我自己的能力是有限的，我要面对的是复杂问题不是我个人或者由若干我这样的个人组成的团伙能够解决的，而应当依靠一支团队的合力。既然需要合力，就应当清楚，自己的偏好不能成为形成合力的负面因素，就应当警觉个人偏好在其中所起的负面作用。对自己来说，这也是挑战成见、修正自我的好机会。