作为员工，你是否有过这样的感受：
leader对自己很不放心，很多细节都盯得太紧，感觉老板不信任自己
leader把架构都设计，数据库，流程，接口都设计好了，自己只是做实现，感觉很没有成就感
leader都不怎么管，压力好大，很多事情不知道怎么做
画外音：员工想，什么时候能当上leader呀，还是指挥别人好。
作为leader，你是否有过这样的感受：
明明很简单，怎么教都不会，还不如自己来
帮下属都安排好了，执行总是出问题
想给下属一些空间，每次交付都搞砸
画外音：leader想，带队伍太累了，还是做好自己的事情轻松，把我撤回去得了。
以上种种情况，都是“授权”的问题，对于新晋管理者，关于授权，这四点一定要注意。
一、思路的转变
很多leader，都是从团队专家提拔而来，ta们在自己熟悉和擅长的领域得心应手。
升级为leader之后，仍然保有原来做事的方式与思路，沉浸在细节里，继续做自己擅长的事情能够“让自己感觉良好”。
这个时候，leader应该将自己的目标，团队的目标，分解转化为下属的目标，完成由“亲自动手”到“指导教练”的转变。
二、口令的转变
回顾一下，作为团队一线专家时，是怎么沟通项目或架构设计的：
1. 这个地方，做了xx设计，以实现高可用；
2. 这个地方，做了xx方案，以实现高并发；
3. 这个地方，先xx，再oo，以保证一致性；
4. 有几个同学在做后端接口，有几个同学在做页面，哪一天联调，哪一天能交付；
5…
作为一线员工，更多说的是做什么（what），怎么做（how），作为leader的时候，就不能总这么和员工下达口令了。
leader，应该更多的说明：
1. 为什么要做（why）;
2. 目标是什么（goal）;
3. 交付的时间是什么（when）;
4. 好的交付标准是什么（criteria）;
然后，给员工以授权，给员工以挑战，充分发挥员工的主观能动性，并在ta遇到风险和困境时，站出来指导他和支持ta。
画外音：有时候不是leader管得细，是口令下达不对。
三、根据员工的类型做授权管理
作为leader，和员工说清楚原委，目标，标准，交付时间之后，要做的就是授权员工，然后拿到结果。
有些leader又反馈了，“我充分授权了呀，但到交付日期时，员工搞砸了，我还得背锅”。
所谓的授权管理，不是简单的放任员工去做而不管，而是要针对不同的员工类型，做不同的管理动作。
在授权管理这一块，员工通常根据能力和意愿会分为四类：
员工能力强意愿低，此时的管理动作是：和员工沟通，找到动力，并做潜在的内在外在激励动作，比如：达成目标时嘉奖
员工能力弱意愿高，此时的管理动作是：安排高阶能力强的员工对其进行指导
员工能力强意愿强，此时的管理动作是：未来应该让员工承担更多责任，并让ta更多的参与到决策中来
员工能力弱意愿弱，此时的管理动作是：辞退
四、授权不授责
权责这一块，很多人的观点并不能达成一致。
有些人认为，应该“权责合一”，既然交给你的事情，你就得想办法做好，做不好就是你的问题。
个人旗帜鲜明的认为，在授权下属这一件事情上，授权不授责，是一个有担当的leader必须具备的品质。
画外音：我分享自己认为正确的观点，欢迎探讨。
leader的工作，确实是把团队的目标，自己的目标转化和分解为下属的目标，授权leader放手去干。但出了问题，没有拿到结果，不也是因为leader自己：
没有及时check和review
没有给与协助，提供资源与解决方案
看错了人
么？
不要让下属背负太大压力，和下属建立良好的信任管理，疑人不用用人不疑，“授权不授责”都是最基础的。
犯了一次错，要勇于替下属承担责任，找到问题所在，帮助下属成长提升。不迁怒。
“不迁怒”的同时，也必须让下属“不贰过”，出过一次错，指出了问题所在，但同一个坑不能踩两次，下属不涨经验，则很有可能是态度出了问题，此时则需要严肃处理。
总结
新晋的管理者，想想自己身上有“管的太细，被下属嫌弃”的状况么，此时可能你需要：
思路的转变：从亲自动手，到教练思维
口令的转变：从传达what和how，转变为传达why/goal/when/criteria
根据员工类型做不同的管理动作：
(1)能力强，意愿低：激励
(2)能力弱，意愿高：指导
(3)能力强，意愿强：赋予更多职责，让其参与决策
(4)能力弱，意愿低：淘汰
有担当，授权不授责，不迁怒，不贰过
场景一
刚毕业那会，有个leader帮我做code review，读到一行时：
他给我下指令：dd
我说，啥？
他又重复了一遍，dd
我当时心底就团起了一股无名业火，别只让我删除一行，告诉我为什么。
场景二
每次路过设计团队，都能听到，雪白的Mac后面，不断的有人在指挥：
粗一点粗一点
深一点深一点
快一点快一点
...
我在想，被“指点”的设计师是什么感受？
据说，每一个设计师背后，都有无数个指点江山的神。
不迁怒，不贰过，共勉
本文转自“架构师之路”公众号，58沈剑提供。
