2021.08/09 OKR总结与反思 && 时间管理

2021-09-30 创建
2021-09-30 更新
4分钟阅读时长

前言

博客好久没有更新了,笔者也是深感到精力不足,无法再维系上半年那样的发布频率。不仅如此,创作的热情也与日递减。在此笔者不得不感叹,时间是宝贵的资产,需要每个人精心打理。

笔者在《十字路口的抉择》一文中曾经提及个人的职业规划,那时在思考技术管理技术专家的路线抉择并最终选择了前者。因此,在后续的近半年时间里面,笔者在字节也逐步建立起自己的团队,并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:提升技术领导力

从完成度来看,只有Objective 4所定义的KeyResult按预期完成。因此从本双月开始,笔者决定放缓技术博客的整体建设节奏,一方面希望文章有更多时间打磨,保障质量;另一方面适度减轻笔者的负担,在团队工作和个人成长中更好地把握平衡点。

结语

继续加油,再接再厉!

Avatar
吴国华 Go语言/微服务/后端/云原生