恭喜升职，也恭喜你遇到一个好老板，
愿意多找人来分担你的工作让你可以专心管理。
最近刚好从 github 看到一篇分享管理原则的文章
（https://github.com/ksindi/managers-playbook/），
以下的文章是从上面这篇的原则再加上一些个人的经验心得分享，希望有参考价值。
网志好读版(抱歉 medium 网址太长只能用缩网址，https://tinyurl.com/yc73rc6t)
1. Always be aware of what’s going on in your team and product.
比起动手实作，主管一定要搞清楚目前团队的状况和所有任务。
特别是当团队越来越大，任务越来越复杂时，
不同专案之间的重要性和依赖程度不同，而主管需要分配资源到那些该做的事情上。
2. Know the architecture just as well as anyone else —
and stay current with the tech stack.
我觉得这点不容易做到，特别是当分工很细的时候。
但是技术主管一定要能问出一些基本的好问题。
像是在设计上有哪些该注意的原则、技术到底要摸深到什么程度才够用、
或是配合不同情境决定不同的设计重点等等。
技术一直在改进，但很多基本面对的问题不会差太多
（像是 security, throughput, latency, cost 这些）
3. Schedule 1–1s with your direct reports on a weekly basis.
Schedule skip-levels on a monthly basis.
沟通可以说是管理者的基本任务了。
每周的 one-on-one 重点不是确认工作进度，而是更关注成员/或主管
在目标理解上的一致以及工作中遇到的困难。
如果团队有好好执行 Scrum 的 retrospective meeting 话，
One-on-one 可以更关注成员本身的状况。
如果觉得 ono-on-one 会议太制式的话，午餐或下午茶的闲聊也是不错的方法。
4. Be customer-focused.
Understand how your products are used in the wild.
在分工分明的大公司这点可能比较不适用。
但是在小公司中，客户就是公司的一切，
了解客户需求和状况有助于设计更好的软件架构或架构选型，
让当前的设计可以满足短期甚至中期需求我觉得是很有帮助的。
（这些需求可能不是 PM 一开始想到或提出的）
5. Set aggressive but achievable goals.
Work backward by focusing on the outcomes you want to achieve.
不管是对上还是对下，设立目标都很重要。
立下明显达不到的目标会让执行者无所适从压力山大，
也会让上层对于公司未来建立错误的认知。
并要将焦点放在 outcome (成果)上，而不是单纯的 output（产出）。
https://www.thebalancesmb.com/inputs-outputs-outcomes-impact-what-s-the-difference-2502227
这边有提到 output、outcome、和 impact 的差异。
例如 tune 好的 model 是 outpout，
但实际上我们关注的是模型上线之后带来的转换（outcome），
以及长期来说，客户是否能在我们平台上停留得更久（impact）。
6. When giving advice or feedback,
encourage ownership by asking open questions.
我不太确定要如何利用开放问题给予鼓励，但是给予建议以及回馈是非常重要的。
建议和回馈是让别人了解自己/团队价值观的最好方式。
每一次 code review、或是成果的检视，都是让团队成员与团队目标校准最好的方式。
我反倒是觉得当成员产出与目标偏离的时候，
可以多利用开放式问题让成员思考其中差异。
7. Be the team coach and cheerleader.
Celebrate success often and reinforce positive behavior.
Coach 和 cheerleader 的角色同等重要。
大家来工作除了领薪水之外，也是希望有成就感和自我成长的。
如果你不太确定 coach 要干什么，
可以参考 NBA 或棒球场上的教练都在做什么就会有比较明确的概念。
8. Know how to differentiate between reversible and irreversible decisions.
管理者第二个任务就是做决策。
小至 coding style 、要不要写注解、座位怎么分配，
到技术选型、架构设计、产品方向等等。
别用战术上的勤奋，掩盖战略上的懒惰。
纵然好的战略也需要好得执行者，但是失败的战略，再努力可能都是徒劳。
9. Ensure every report is aware of the top priorities of the team,
organization, and company.
呈上，做决策中很重要的一件事就是决定优先级。
确保大家不是瞎忙或内耗。
10. Be the example. Only preach what you practice.
纵使管理者可能不会做每一个技术细节，但是价值观唯有靠自己实践才能传递。
如果不是一个正直的管理者，团队也不会是一个正直的团队。
坚守原则最简单的方法就是一次都不要违反。
如果你违反了一次，那就会多出一条原则的额外规则，以及更多违反原则的机会。
11. Get your hands dirty even if it’s not coding.
就算没有写扣，还是有很多方式可以帮助团队，
像是写文件、未来规划、新知识的分享、找问题、提升成员技能等
管理上能讨论的细节和状况真的太多，
而且也需要反复尝试和练习才能找到适合自己和团队的方法，希望你一切顺利。
※ 引述《Masakiad (Masaki)》之铭言：
: 恭喜你升任主管，也对于你愿意认真带领团队，甚至不惜直接上来Po文讨论，感到尊敬。
: 毕竟在这位置要打混装死，也是挺容易的。
: 因此也分享一些经验；
: 首先这个位置主要是重建/维护/改善一套软件生产系统，这系统关联的当然有产品、人、
: 工具。所以所有你执行的内容，背后也是考虑这样的大前提去运作。
: 换句话说一个好的主管，每一个导入的政策、计画、管理工具等等时，应该都确立出这系
: 统局部目标，并且应该可以量化执行的结果方便分析跟稽核效果是否预期。
: ※ 引述《imasaka1117 (Teddy)》之铭言：
: : 大家好@@
: : 因为小弟去年被升为技术主管(小公司)
: : 一开始底下只有一个人
: : 到现在已经有四个人了
: : 因为刚升的时候
: : 专案的量还很重
: : 所以其实没做什么主管该做的事
: : 顶多只有帮忙看其他人遇到奇怪的Bug或是技术上问题的讨论而已
: : 一直到最近老板说要再招募一人减少我的loading
: : 让我有时间去做主管该做的事
: : 刚升主管的时候老板有提点我一些主管该做的事
: : 像是
: : 1.task review
: : 我的想法是每周开例会来让大家报告做的事项
: : 但又觉得好像没必要，因为PM都会知道RD们做的事情
: 虽然单纯是执行task review，但根据背后确立的局部目标不同，会直接影响进行方法跟
: 思考方向。因为你默认了PM知道即可，那么这好像没必要。
: 事实上哪些人需要task review 以及频率该多久一次的才是真正命题；从我过去经验是PM
: 外，技术主管也该知道，每一个工程师也该知道。然后其他越多人知道越好。最后我建议
: 是每天进行，而且10分钟内搞定。
: PM的目的显然是为了方便产品与市场或客户衔接。
: 而技术主管的目的应该是“产品开发的顺利运作，维持产值的稳定性”。所以review 必
: 须除了让你知道生产中细节，进而快速排除开发障碍外，还必须量化产能。量化非常重要
: ，因为他是发现异常的依据，更是你跟其它部门谈判的工具。千万记得，不是压开发时程
: 的工具。压开发时程这种事情应该是PM做。然后你来挡。
: 举个例子来说，一个做完量化开发产值的team，应该可以知道该排入多少的工作量。而当
: 有突发状况，像要hotfix时，外部串连服务挂掉、突然改版等等时
: 1. 由于每天都知道各自进程状况，会更容易找到适合的人来负责突发状况，也更容易预
: 估会减少的开发产值。
: 2. 由于工程师都知道各自每天的进程，所以也更容易提供你适时的建议。
: 3. 由于增减的产能都有纪录及量化，也更好有依据去抵挡PM的不适合的压时程问题。PM
: 一周一次检视很容易忽略掉或错估处理一些突发状况的时程。
: 其他：
: 1. 透过每一天自我检视，再加上PM不会无理压时程，让工程师可以专心每一天的工作内
: 容。因为你知道工程师都要热机的麻。
: 以上目标都是“产品开发的顺利运作，维持产值的稳定性”
: 另外有量化数据让你争取资源更容易，比如招聘、添购硬件设备、外部服务或开发套件。
: 只要有数据，谈判就顺利。实行后也可以有数据分析跟稽核，再来就可以邀功。记得一定
: 要邀功，你越红才有机会把更多想做的导入。
: 还有一个重点是，每个开发团队适合的作法不一样，比如也有可能每天对你们没什么增益
: ，但透过量化分析持续修正，适时回想目标，找到你们团队的最佳解，这是技术主管必须
: 做的。
: PS. 该写内容的实在太多，但是真的要都写完太长，最后会导致我直接不发。希望短短的
: 内容有帮到你。
: : 2.公司未来技术方向
: : 因为程式人生是需要不断学习的
: : 公司也是，不然也会被业界淘汰
: : 我是希望可以带着每个RD成长
: : 这个倒是没有什么异议
: : 但如果决定了某个方向也是会和RD们讨论
: : 看是不是有盲点
: : 3.提升RD工作效率
: : 这点应该就是会想破头的XD
: : 因为公司的PM有些是非本科的
: : 客户如果发问，他们不懂的话就会pass给RD
: : 有时候就是一些基本问题，然后RD工作就会被打断
: : 所以我是想说给PM教学一些资讯业相关基本知识或术语
: : 另外就是观察RD们的IDE操作或是找解答的方式，并给予更好的建议
: : 例如鼠标点两下可以直接反白该单词，而不用鼠标拖拉之类的
: : 当然有时候反而是我看到他们更好的操作是我该学的，也要记下来给大家知道
: : 4.统一coding style
: : 这点主要是防止人员临时请假或是离职，交接时痛苦指数会比较低
: : 当然还有如果多人合作时就较不会有违和感
: : 以上是目前觉得该做的事@@
: : 另外还想问各位是否还有哪些是我没想到且建议的吗?
: : 先谢谢大家QQ