前言
博客好久没有更新了，笔者也是深感到精力不足，无法再维系上半年那样的发布频率。不仅如此，创作的热情也与日递减。在此笔者不得不感叹，时间是宝贵的资产，需要每个人精心打理。
笔者在《十字路口的抉择》一文中曾经提及个人的职业规划，那时在思考技术管理和技术专家的路线抉择并最终选择了前者。因此，在后续的近半年时间里面，笔者在字节也逐步建立起自己的团队，并push自己加强对管理的学习和思考。
管理者的时间管理
笔者观察到，有非常多新迈入管理领域的同事，会很快彻底地抛弃技术化身为纯管理者，从而化身类似“项目经理”性质的角色。笔者则一直对这样的转型有所顾虑。因为笔者一直固执地认为，管理者更加需要是团队的专家。在技术领域，每个员工都会对技术专家产生发自内心的尊重，这本质上是对能力的一种认可。因此，一个技术强劲的管理者能够对团队有天然的号召力。
但不得不说，管理者的时间毕竟是有限的，因此管理者绝对不能陷入技术细节的泥沼当中。换一句话说，管理者大概率是对技术细节/代码细节最不了解的人，但却应该是对全局架构/上下游最了解的人。
那么管理者的技术成长应该如何去落地呢？
笔者在近半年的转型当中，也深刻理解到成为管理者之后的技术成长路线与之前是截然不同的。管理者真正需要的能力是把控团队的业务发展、技术方向、资源规划，即成为团队的掌舵者。与此同时，管理者又不应该成为阻碍团队发展的那个人，即管理者绝对不应该替代团队成员去完成本该他去做的事情。做管理正如做架构，如何取舍是核心的能力。
那么落地到技术成长里面，笔者的思考结论是：把控整体的技术轮廓，将繁重但有提升的技术细节交给团队的成员，让彼此之间都能有真正的提升。因此，本质上管理者需要的是开拓意识，团队成员需要的是稳固意识。管理者应当向外去request更多的资源，更多的输入，来拓宽团队成员的认知边界，再推动团队成员在深度形成壁垒，这是一个团队健康发展的正确打开方式。
其次，管理者的技术和管理比重应当如何把握呢？
笔者认为，答案是审时度势。优秀管理者之所以稀少，正是因为许多管理者局限于自身的能力和视角，或者对某些金科玉律奉为经典深信不疑。管理者应该做的事情，可以是在初期编写核心代码，但不可以是始终编写核心代码；可以是在团队中树立规范，但不可以是在紧急情况下拘泥于规范。管理者要做他人所不能，在团队缺乏技术攻坚时候，承担技术决策和后果，甚至于直接参与编码；在团队缺少信息同步时候，及时建立站会/周会/月会；在团队松懈时候，启发大家思考架构提升；在团队紧绷时候，组织团建释放情绪。
总而言之，管理者的时间管理是一门学问，笔者只能说是初窥门径，仍然需要不断积累不断学习。
8、9双月OKR总结与反思
很惭愧，笔者在上一次的06/07双月的OKR总结与反思中，已经发现无法保障个人技术博客的创作进度，本次08/09双月的进度则彻底暴露这个问题。
- Objective 1：深入理解云原生核心存储——etcd
- KeyResult：理解分布式共识算法raft，基于hashicorp raft库深入raft实战，沉淀1篇博客。
- KeyResult：理解etcd底层存储引擎，沉淀1篇博客。
- KeyResult：深入理解etcd watch机制，沉淀1篇博客。
- KeyResult：完成极客时间《etcd实战课》剩余实战篇的学习。
- Objective 2：理解资源调度
- KeyResult：深入go的runtime层，理解MGP调度，沉淀1篇博客。
- KeyResult：深入Kubernetes的调度器，理解scheduling framework，沉淀1篇博客。
- Objective 3：架构设计精粹系列
- KeyResult：总结1个业务场景的架构设计，沉淀1篇高质量的博客。
- Objective 4：提升技术领导力
KeyResult：总结跨部门协作的经验，沉淀1篇博客。《谈一谈跨部门协作》
从完成度来看，只有Objective 4所定义的KeyResult按预期完成。因此从本双月开始，笔者决定放缓技术博客的整体建设节奏，一方面希望文章有更多时间打磨，保障质量；另一方面适度减轻笔者的负担，在团队工作和个人成长中更好地把握平衡点。
结语
继续加油，再接再厉！
