下述内容，为阅读完《技术领导力》结合自身经历而来，有摘要有感悟~~
领导力（Leadership）指在管辖的范围内充分地利用人力和客观条件在以最小的成本办成所需的事，提高整个团体的办事效率的能力。
在新公司做了1年的小leader，自己感触还是很多的，再加上最近遇到的一些事情，特想梳理一下自己关于管理的一些思绪~
- 刚进入公司时，自己的压力和生活节奏完全被打乱了，每天压力巨大，想逃避~~~
- 慢慢的得到了公司领导和同事的认可，开始了新的规划、流程、制度，为了是想把大家凝聚到一起，完成工作之余，可以快乐的讨论技术~~~
- 现在，对于整个环境太熟悉了，但怕在这样环境下变成自己不喜欢的人的样子，想突破想改变~~~
与此同时，自己的整个状态、对待事情以及感悟也在发生着变化：
- 下属工作没有达到自己的要求，沟通比较费时，自己去做~~~
- 感觉自己的技术在退化，长期不写代码感觉自己价值在下降~~~
- 发现自己不懂的东西越来越多，疑虑自己为别人争取到的利益的认可度，认为想把管理做好不太容易~~~
硅谷的大公司的 CEO 很多都是印度人，比例差不多达到了 5:1，中国领导者却寥寥无几。主要是因为我们更多的时候将自己看作是一个技术专家，有很强的执行力；但严重缺乏远见卓识（战略思维、商业敏锐）、机制应变和建立关系的能力。所以我们经常会听到这样一句话：“一定不要把技术丢了，在这个公司干管理，去了另外一个公司可不一定，但技术可以的”。
是的，对于技术管理来说，技术在前，管理在后，成为技术大咖是做管理的第一步。我们可以花70%的时间在技术上，花30%时间在管理上，但需要用这30%的时间做完100%的管理工作。在技术方面，要以CTO为榜样；管理方面，则应该像CEO一样思考。
技术管理
做技术管理，掌控都是基于权威影响力（技术说服力），而不是基于职位的 。我们需要关注的问题不再是某个具体的技术与实现，而是事情。“技术的业务派，业务的技术派” 是技术管理成熟的标志。决策务求十全十美，注意把握大局。
上得“厅堂”，下得“厨房”，忍气吞声，专业背锅 这是对技术管理不错的总结。遇到问题时，不是“跟我冲”，而是“给我上”。欲管理人、必先了解人。在埋怨领导、下属之前，应该多多自我反省，是不是工作职责没有承担起来，是不是自己为人处世的方式让别人很难堪而不自知，是不是开口闭口都是以自我为中心。不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，都不要让你的上级陷入困境。要理解人性，善用策略。克服从众心理；增强自信心；要具有成就他人的心胸（情商），以及一种感恩的心理。
如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们去憧憬广阔无垠的大海。
成功并不只在于你做了什么，更需考虑别人如何看待你所做的成果。被认可的方式无非这两种：要么你聪明，会交际，懂政治，被认可；要么你做出成绩，贡献巨大，被认可。那些民意很棒，成绩一般的人，只能称之为烂好人，他们将善良发挥到极致，从而变成了一个无原则妥协的人。
同时要把握技术人员心态成长阶段：感知阶段（接触大量新技术，积累经验）；深入阶段（清楚方向，着手实践）；突破阶段（发展瓶颈，独立思考，适度授权）；创新阶段（认真倾听，给予掌声）。
团队建设、人员管理
技术团队需要有自己的愿景，技术愿景来自：客户实际需求；测试数据；外部公司技术资料。
不懂技术的技术领导最典型的问题：压力传导问题，业务方收到了客户的压力，本可以通过向客户解释来减少研发的压力和风险，但是选择直接施加研发。对技术要有一颗严格和敬畏的心，想清楚了再干，坚持高标准，很多事情都急不来。
懂技术、高情商的管理者才是人才。对于人才，我赞同这样一句话：
“一流人才招聘一流人才，二流人才招聘三流人才。” – 史蒂夫·乔布斯
不同级别的人看待事物、人的角度是不同。聪明的人很清楚面试过程是体现了一家公司的技术能力、思维和管理能力的绝佳途径，所以我们绝不可以轻率应付，你代表着公司，而不仅仅是你个人。
STAR面试法：situation背景（工作业绩有关的工作背景，了解其个人贡献）、task任务（每项任务内容，了解其工作经验）、action行动（如何完成工作的，了解其工作方式和思维方式）、result结果。
然而团队中，我们需要各种级别的开发者，这就需要我们学会将人员分类，便于更好的管理：
- 独狼（遇到问题独自解决、方案往往是一次性的）和农民（有条不紊、按序就班）；
- 英雄（薪资和福利都要有所倾斜）；
- 内向的人（多鼓励）；
- 带有明显负能量的人（不要总是给自己找很多借口，实际上就是懒或者养尊处优习惯了，有困难就解决，发牢骚、推脱，并无任何意义）。
对于不同级别的开发者，我们需要不同的Flag，但考核规则要量化、用事实说话。我们可将OKR和API相结合。**OKR关注的是目标，KPI关注的是指标。**OKR可以让我们做正确的事情，KPI让我们正确地做事情！如果方向对了，就不怕路途遥远！如果方向不对，指标再漂亮都没有意义，甚至指标越漂亮错得越离谱。
考核背后的就是薪资和奖励，薪资是第一要务，一定要把握标准，做到公平、公正，不然你的团队会垮的。
- 按能力和付出衡量，不把个人情感混淆其中；
- 标准化考核规则，输出信服的流程和细则；
- 多元化组成，感受到每一份多的付出和回报；
同时也要坚信感觉被尊重，胜过加薪。鼓励大家的，同时可以带来不同的创新思维，但也要明白创新无疑需要批判性思维，批判是有益的，但我们需要批评过后的冷静思考和实际行动，始终要将“批判”和“批判性思维”区分开。批判只为对某个事物的否定；批判性思维是通过否定来寻找更好的做事方法。单纯批判是消极的，而批判思维是积极的。
过程管理
产品开发过程往往会出现：工程延期、Bug丛生、沟通冗长、人心浮动。此时更要禁忌：需求不明确直接开发；先编码后设计。这样会产生更大的问题~
把握业务和技术的关系，业务看的是今天（或者是短暂的明天），而技术放眼的是未来。当然，技术只能支撑了业务，你才有未来，不能解决当前业务问题的技术人员，不要谈理想，因为只有能够解决问题的人，才配谈技术理想。喜欢这样一段描述：如果我们把程序源码看成一篇文章，那么这篇文章的词汇，就是各种变量和函数的名字。如果我们在命名上困难重重，那么这篇文章也一定晦涩难懂。（词汇量小或者业务领域不了解）。
我们要把技术当做解决增长问题的一种手段和工具，而不会被技术束缚住。架构师（技术管理者）都要有觉悟，理解并发现问题永远比解决问题更加重要，遇到问题首先进行分析，不要急于解决问题。架构师（技术管理者）需要跳出技术的视角，换一个角度去看技术。把时间花在研究生命周期规律和业务的增长上，而不只是追求新潮的或自己喜欢的技术。现实生活才是架构师（技术管理者）正真的营养来源。
对于技术选型，首先了解系统存在的问题、产品未来的走向和技术团队的现状。
- 根据社交媒体讨论来决定哪种框架；
- 跟风走，哪个热门选哪个
- 坚持通过技术评估手段进行选型
技术方向需要通过技术调研、技术预研帮助团队成员逐步认识、理解和明确，这是一个必然的过程，我们应充分重视并直接参与。技术调研，是一项工作，不要沉迷于学习。
最后，过程的结束需要复盘。带着问题去思考才会有收获，这就是复盘。复盘会不要太严肃，它不是“批斗会”，而是为了总结经验，不断优化，不再犯同样的错误。
总结
酒香，也怕巷子深。对于自己的工作要有热情和使命感，没有使命感，是无法用言语影响他人的。
持续学习，终身学习；不求一鸣惊人，但求独善其身。将编程看做是一门艺术，热爱和用心会换来相应的成绩。我所做的工作是：“把人类生活的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效的新生活，让核心生命周期的运行能够更加容易，让非核心生命周期的处理更少地占用人类的时间，变相地延长人类生命。”O(∩_∩)O哈哈~
后续（下述内容均来自知乎）
- 管理是手段，为了管理而管理，正是刻舟求剑；
- 匹配比优秀更重要，胜任比卓越更现实；
- 管理者最重要的职责就是找事情做，下属无事可做就是管理者的失职；