领导者必备:三元简化模型,助你加速团队成长

简介: 在雀友会分享交流了关于成员成长和组织发展的话题,围绕成员成长做了一下文字沉淀。

关注成员成长

很早之前,现代管理之父德鲁克提出过一个影响深远的观点,“21世纪的组织,最有价值的资产是组织内的知识工作者和他们的生产力。”现代企业的各位管理者,遇到最大的两类问题就是战略和组织,看不到、想不到、做不到,这“三不到”的问题归根结底都是人的问题。能够看到、想到、做到“重视人才”的企业,成功的概率总是会大那么一点点的。你的公司呢?

阿里有一句话流传甚广,“员工是公司借给你的资产,你的责任就是让他增值。”作为组织力溢出的阿里,这句话是很值得我们深思。早年在阿里的时候,曾在内部分享时听马老师明确地说过,阿里巴巴就是“客户第一、员工第二、股东第三”,当然这条至今应该也没有变过。相信“客户第一”这句大家都认,“员工第二”呢,你怎么看?

作为一个企业,活下去是最大的使命,公司的各位管理者都需要在不同的层面不断的思考,如何才能够让企业持续发展,并且越来越好。在不断向外看、向外寻、向外学的过程中,希望都留出足够的时间给内部,给成员。


1566113450251-3993ce59-e8c6-4e67-a920-215ea9d25751.png.jpeg
(感谢校宝小伙伴提供的照片)

成员的判断标准


1566114563222-2b328012-8804-4b47-8fc3-b60a159e592e.png

团队成员在成长时,其实很希望获得类似玩游戏时打怪升级的快乐体验的,所以我们需要给团队成员一个可以看得见点得亮的技能树。这个技能树是团队成员成长的判断标准,一般HR是称之为“胜任力模型”,但我这边主要是自己的一些经验总结和知识沉淀,还不够成熟和体系化,所以大家当做是简化的判断标准即可。这个判断标准包含三块内容,能力、经验、认知,分别对应于“你能做什么”,“你做了什么”,“你知道什么”。

首先是左下角的能力这块,这块是绝大部分管理者都熟识的,也是应用相对最好的。我这边简单的再做了一下小分类,以开发的同学为例,专业能力我们会关注开发语言的学习能力、框架的应用和改造能力、技术重难点的攻坚能力、故障问题的定位能力等等;通用能力我们会关注理解能力、总结能力、表达能力等等,高阶一些我们会关注共情能力和领导力等等。这块有很多更体系化的归类描述,我就不班门弄斧了。

比较希望引起大家关注的是其他两个判断标准,关于经验和认知。

关于经验

经验和能力很容易搞混,判定你能做这个事情,你就应该有相关的经验。其实这里有一个误区,能力获得的方式有很多,直接看书习得和亲身经历获得。不是说看书习得的能力就不是好能力,但是作为管理者,我们问问内心,如果要做一个项目,是找一个已经做过很多次项目的同学,还是一个可以把项目管理说的头头是道但没有实操经验的同学?不是全面否定纸上谈兵,但确实纸上得来终觉浅啊。对于经验,这是需要关注的第一层。

需要关注的第二层是失败的经验。成功经验很宝贵这个就不展开了,大家很容易理解。大家可以停下来考虑一下看,有过成功经验但没有失败经验的人,他去重复成功之路时,这个路径的适应性到底有多强?很多时候是突破认知的,突破的是他自己的认知,更是启用这个成员的管理者的认知 -- 因为我“不知道自己不知道”(这个我们一会展开聊)。我们一定要小心那些赢了但不知道怎么赢的人,相对的,那些失败过的人,即使是赢了,他对于成功,也是会保持敬畏和反思的,这个思维很重要!然后,使用有失败经验的人也需要小心,我们不要去用屡战屡败的人,运气这么差不行啊(开个玩笑)。但我们确实是要敢于去用屡败屡战最后能赢的人。


1566135059328-95b9e4d9-4911-47f5-87d9-ea84d3024b72.png
(我老大推荐给我的一本老书《大败局》,也推荐给各位)

举个栗子,在运维届有一个千年老梗,“我执行了rm -rf /,现在怎么登录不上去服务器了”。有过这个经历的同学应该这辈子会被运维界封杀。但是,我们思考一下,这个失败的经验真的是永不录用的点吗?做了这个事情的小菜鸡,在真的理解了自己做了什么之后,他对于运维、对于系统甚至对于知识,应该这辈子都会有敬畏之心了吧,对他自己来说,一个命令、一个参数、所处环境没搞清楚,绝对不会再去冒冒然执行的了;对团队来说,这样子的人成长起来以后是可以交出自己的后背的。(话外音:如果不幸有雷同的故事,我们应该思考一下制度规范、管理约束、执行监督这块,这些东西以及和这些东西有关系的人,更应该被重点关注!)

关于认知

认知是一个很大的话题,前面的描述“知道什么”,更多的是你沉淀的知识的多少,这里想跟大家具体聊的是“怎么去理解和认识自己”。认知的四阶段,成员的自我认知,是直接影响他的成长的。
我举软件项目的一个栗子帮助大家感受一下。“我们要去快速占领小程序的入口,谁来看看怎么做一个小程序”,这时候,前端一两年经验的小白跳出来了,我来吧,web端移动端的我都做过了,小程序也不会有什么不一样的;与此同时,从后端转去前端的技术专家提出了不同的看法,小程序看起来是一个不太一样的技术体系,我们还是先去研究一下再做判断。


1566136119518-f97ad201-63cb-4686-84e1-78e26c3255af.png

不知道自己不知道,这个状态其实在团队中很多的,一个人是很难完整的在这个状态里的,有可能是一时,也有可能是一事。我们一定要能够正确地识别出来,在这个状态中是比较盲目,比较冲动,也比较无畏的,就像故事中的小白一样,这不是一个好的认知状态。

知道自己不知道,这个状态在团队中其实也很多,绝大部分优秀的人都是在这个状态被识别出来的,而不是大家以为的“知道自己知道”。我个人认为这是一个比较好的认知的起步状态,很像是一个脚已经放在起跑器上的跑步运动员,重要的是,发令枪也在他自己手上。这个状态的中的同学总是很谦虚,有敬畏之心,行事相对谨慎。

知道自己知道,这是一个比较优秀的状态了。这个状态中的同学,知道自己知道的边界,会尽力把事情控制在自己可控的范围内。

不知道自己知道,这是一个卓越超凡的状态了。这应该是一种打通了任督二脉去学习武林绝学的感觉吧。

成员的成长辅导


1566136344344-a4a005aa-cee8-4dbd-85d7-25e2bbf6307c.png

经验相关

前面一节提到,我们要放开对失败经验的成见,敢于启用有失败经验的同学。那对内,我们也应该要敢于让同学尝试可能失败的事情,也应该要放开必须成功的紧箍咒。成功学的书很多,我们却硬要来聊聊如何帮助“失败”(因吹丝挺)。

我们首先明确,我们不是为了失败而失败,是为了成功正视失败。在成功的道路上,我们允许荆棘也允许坎坷。怎么做?首先第一点,“控制黑边界”,失败是一个完整彻底不可控的失败,还是一个部分暂时掌握中的失败,差别很大。我们一定要控制好失败的边界,失败尽量不影响最终结果,失败尽量不影响太多成员。尽可能让可能的失败在掌握中,前期,管理者一定付出大量的脑力、体力和心力,就可能出现的风险点做出充分的预估,做好完善的保障,保证出现失败时整体可控。第二点,“总结全经验”,有没有做总结分析,有没有做思考沉淀,是衡量这次失败价值和意义的分水岭。没做总结,白失败了,经验值都给别人了。出现了失败,不但要总结,还要尽可能的全面总结,这个当事人自己要把这个失败的前世今生总结到位,把再来一次可能成功的路径一定要找到位。同时,跟这个失败有关系的所有同学,要一起参与进来,不是来讨伐的,是来一起思考、一起共创的,从不同纬度、不同角度,把这个事情的上上下下里里外外弄个清清楚楚明明白白。(这个事情上,曾经地阿里“太白”--白老师、现在的校宝COO--杰哥,宇宙无敌,只要这个阵地他敢把旗子插上去,就没有我们不敢冲上去的,原因就在这里,带着大家赢,输了也是赢,最终一定赢。)最后第三点,“出发再启动”,已经失败的同学再次踏上征途,无论之前的总结多么的到位,心情总是有所起伏的,出发前,作为管理者一定要做好启动的动作,要告诉他,为什么再出发,再出发为什么能赢,把成功的路径指给他看,重点就是要把他的状态调整到位,要把他的情绪引导到位。

认知相关

认知四个状态中,最不好的状态就是“不知道自己不知道”,如果深陷这个状态无法自拔的同学,建议不要去做只有神才能做到的事情了。但对于只是某一时间段或者是某一个具体事情上无法突破的,我们要尽可能的辅导帮助。如果真的是一个好的同学,从不好的状态“不知道自己不知道”到起步的状态“知道自己不知道”,我们要做的事情其实也比较简单,就是让他看到。比如之前小程序的故事中,在小白看到了技术专家拿出来的技术可能性分析、技术方案后,我相信他会进化的,毕竟我们大部分人都是这么过来的。“看到”是不好的状态进行跃迁的基本辅导手段,后面的状态的跃迁,需要的是更多成员自身的主观能动性了,我们之后有机会再聊。

成年人不会轻易改变自己,除非他自己想改变,认知的变化可以理解为改变一个人的心智,其实是一件非常难的事情,所以如果你有幸做到了,请相信,你只是遇到了一个优秀的同学,不代表你就是一个优秀的管理者了。

大道至简


1566121495411-608534a8-5c67-4312-bb38-a7c45d8cbbb7.png

最后跟大家分享传奇CEO-杰克·韦尔奇在《商业的本质》说的一句话,希望大家能在管理之路上越走越实。

语雀原文链接在此

相关文章
|
3月前
|
供应链 数据可视化 开发者
无代码究竟是什么神秘力量?哪些人能借此开发业务系统,开启高效数字化转型之旅?
【8月更文挑战第20天】无代码开发是在数字化时代兴起的技术趋势,通过可视化界面而非传统编程语言来构建应用。开发者利用预设的功能模块和组件,简单操作如拖拽、配置属性即可快速搭建业务系统,如客户管理或任务追踪。这种方式降低了开发门槛,加速开发流程,且具有良好兼容性。尤其适合预算有限的小型企业主、熟悉业务流程的部门人员及需迅速验证商业模式的创业者。通过无代码平台,他们能高效地创建满足特定需求的系统,促进业务发展与创新。
56 2
|
6月前
|
Cloud Native 算法 程序员
代码与禅意:编程中的哲学思考构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第30天】 在数字世界的繁花似锦之下,编程不仅仅是一种技能,更是一场关于逻辑、美学和哲学的深刻对话。本文将探讨编程过程中所体现出的哲学理念,从禅宗的角度出发,揭示代码背后蕴含的深层次意义。我们将一同走进程序员的内心世界,体会在面对复杂问题时,如何通过冥想般的编码实践,达到问题解决的顿悟。
|
6月前
|
设计模式 微服务
从代码到架构,我的技术成长之路
【2月更文挑战第5天】技术是一门不断进步的艺术,我在不断的实践中,通过学习和思考,逐渐领悟到了代码、架构等方面的知识和技能。在这个过程中,我发现技术并不仅仅是一种工具,更是一种思维方式和生活态度。本文将分享我的技术成长历程和所获得的思考。
54 2
|
人工智能 Kubernetes 前端开发
未来3-5年,前端低代码化,具体往哪个方向发展更好就业?
未来3-5年,前端低代码化,具体往哪个方向发展更好就业?
|
人工智能 自然语言处理 前端开发
探索AI时代的应用工程化架构演进,一人公司时代还有多远?
当代AI来势汹汹,本文从AI的特点、对研发的挑战、AI的应用工程和场景分化等剖析了AI时代的应用工程化架构演进之路。
20930 6
|
存储 人工智能 算法
探索 AI 时代的应用工程化架构演进,一人公司时代还有多远?
序言 在当下生成式模型的 AI 时代,了解和使用 AI 相关技术是前后端研发同学迟早要面对的事。 所有产品都值得用 AI 去重新做一遍。其根本原因在于当下 AI 的形态即生成式模型是通过 AI 辅助来改变和创造新的产品形态,而不是像以往的技术一样只是对现有产品形态的补充。 简单来说,产品研发同学可以做的事情更多了。
186 0
|
数据可视化 BI 测试技术
一文吃透低代码平台的衍生历程、优势及未来趋势
一文吃透低代码平台的衍生历程、优势及未来趋势
121 0
|
前端开发 JavaScript 小程序
新来个技术总监,给公司项目引入了全新的业务架构,堪称最佳实践!
新来个技术总监,给公司项目引入了全新的业务架构,堪称最佳实践!
|
存储 架构师 BI
【业务架构】业务架构:战略执行之路上缺失的艺术/科学
【业务架构】业务架构:战略执行之路上缺失的艺术/科学
【业务架构】业务架构:战略执行之路上缺失的艺术/科学
|
程序员 开发者
什么是全民开发?|概念、技能和优势
国内普遍将Citizen Development翻译为公民开发,但草料二维码认为Citizen Development并不一种技术,而是一种工作模式和规范,应该被翻译为全民开发,即每一个懂业务的人都可以成为开发者。
145 0