顾问、老师及教练

开发 开发工具
由于工作的原因,这些年接触了很多的公司和团队,大家对我的称呼也各不相同。有叫肖顾问的,有叫肖教练的,还有叫肖老师的,这引起了我的一些反思。

由于工作的原因,这些年接触了很多的公司和团队,大家对我的称呼也各不相同。有叫肖顾问的,有叫肖教练的,还有叫肖老师的。最近一直合作的一个企业举办了规模不小的教练大会,引起了我的一些反思,于是想撰文跟大家分享一下在教练、顾问和老师这三个头衔上的认知,不一定正确,权且写出来跟大家切磋。也希望能唤起正处于数字化转型时代企业对自身教练力量建设的关注。

解决问题的顾问

实际上我的工作多是顾问,邀请我的企业或团队一般都希望我能够带领他们解决某些“问题”。为什么问题要用引号呢?原因是很多企业和团队初始描述的要求其实不是问题,比如“我们没有单元测试,帮我们搞TDD吧”。作为顾问,我要做的***步是发现真正的问题,当然这个过程中有很多技巧,并不是本文的重点,按下不表。

作为顾问的一个基本要求是很了解自己的行业,并且有不少的相关经验,比如企业请我去一般都是做软件产业相关的工作,决然不会请我去做投资管理顾问(显然我自己也错过了比特币)。原则上顾问工作是给出客户面临的客观问题和挑战(也包含组织及团队的赋能问题)的解决方案。

[[220647]]

从纯粹意义上讲如果已经给出了详细可落地的解决方案,顾问的工作就完成了。可能由于我个人资历尚浅,解决方案即使得到认可也还是被要求必须负责落地执行(至少一个试点团队是必须的)。我也见过不少银发顾问给了一个PPT就能够赢得客户最终认可的。当然在软件行业可能这样的情况会越来越少。

所以顾问这个头衔在我的认知里就是一位能够帮助企业和团队发现自身问题根源,并设计解决方案的人。

推动改进的教练

为什么不少项目上也有人叫我肖教练呢?想想大抵是因为不仅仅给出了一个自认为合理的解决方案,并且需要带着核心人员实施。为了能够落地解决方案,一般我会要求客户团队成立教练组,和我一起来承担改进任务的执行和反馈调整。这个时候大家自然也开始叫我教练。

教练这个头衔比较有意思,一般客户方负责人都会问我咋选教练,经过这两年的揣摩,我个人比较认可两点:***、主动交流沟通好的;第二、自我驱动推动能力强的。注意这里我并没有要求专业能力,比如需求管理改进并不一定是一位资深的BA来作为教练。

为什么这样要求呢?因为改进工作无疑是破旧立新的一个过程,无论是烟斗曲线还是U型理论实际都告诉我们这是一个先抑后扬的过程。即使咨询顾问给出的解决方案是***正确的,也可能因为下挫的过程中无人扶正而被团队所放弃。

推动改进的教练

(图:著名的改变烟斗曲线,每个改变都要经历一定时期的痛苦Frustration和挣扎Depression。而这个下挫的过程是最需要关注和扶正的。)

一些组织确实能够通过行政手段保证下挫的过程中也可以“削足适履”的落地,但确实极其少见,也不建议效仿。大多数组织都需要一帮专注改进方向、持续鼓励团队的教练。而且很多时候这些教练还需要专职专用,把推动团队改进、扫除改进障碍做为自己的工作目标。

有人会说“程序员激励师”就是教练了!如果你的改进目标是让几个开发人员自信心爆棚,多写两三个功能,确实也可以算。但改进工作其实是很严肃的,事关一个组织未来的存活,目标也是全组织共享的,涉及整个组织各个角色和部门。这个时候不是简单让几个员工“high”两天就能转型的。所以教练也是一个长期工作,需要卷起袖子和团队一起实干落地。

那如果没有相关的专业能力,怎么能够落地呢?不少同事和客户都知道我也经常调侃高谈类似打坐参禅的业内“教练”为“走心流”。原因当然不是我想用“你会写Scala吗?”这样的问题去怼人,而是教练的核心工作是去务实的影响一个正在改进道路上下挫的团队,让他们坚定信心和方向。在这点上不是教练个人的修为重要,而是如何影响团队重要。如果参禅打坐能够感染团队,提升士气,实际上也无妨。但咱们这个行业毕竟有很强的工程学基因,恐难完全从悟道的角度去解决问题。

[[220648]]

然而这并不是说教练一定要是某个改进领域的技术专家,而应当是一个引导者:这个引导者能够帮助团队建立改进的共识,持续反思改进过程中的问题;同时又是一个催化者:像催化剂一样让团队能力得到放大。催化剂这个说法《人件》中早有论述,我认为应该是一个教练的***目标!

比尔盖茨在自己的TED演讲上说“所有人都需要教练”,论述了包括老师在内的每个人都需要一面会说话的镜子,才能够持续提升。良好的教练可以根据团队或个体希望改善的具体领域提供可行的见解和发展机会。这个改进的过程中目标必须清楚,成功标准必须明确。 但不管是改进目标还是成功标准,都不是教练制定的,而是改进团队或个体在教练的引导下完成的。

传授技艺的老师

老师也许是我最早的一个工作头衔,大学勤工俭学的时候,助教是我最喜欢的一份工作,每次上完一堂辅导课总是感觉一天十分充实。然而经常的困扰是学生们提交上来的作业五花八门,看得哭笑不得的也不在少数。

从那个时候到现在我都还是比较相信“没有不愿学习的学生,只有不会授课的老师”。当然老师并非是越资深就越会授课,比如我敬爱的博导一辈子都不喜欢授课,反而每年给了我很多机会去体会怎样做一个好老师。一个好的老师能够把一个知识点用不同的形式演绎给学生,让整个课堂的氛围变得活跃,有时候甚至是学生们自己在推着课程一步步深入。

[[220649]]

对于我的导师来说讲课是痛苦的,因为总是要求他年复一年重复类似傅里叶变化这样的公式,但对于好的老师来说,每年可能都会有新的角度来讲授看似死板的公式。某种意义上这是对技术知识点认知的一种深入,把认知本身做为了一种匠艺来追求。正是在这方面的兴趣,促成了教学上的热情,把认知的传递作为了工作的回报。当然这样的人其实并不多,也是非常难坚持的,如《中国合伙人》中的主角成东青把终身热情奉献给讲台的老师是值得尊敬的。

不同的胜任力要求

回想自己的工作,其实即使在一个项目上也可能随时切换角色,比如调研分析时我是一名顾问,试点项目上我是一个教练,规模推广时我成了一名老师。但既然分析,就希望能够看看这三个角色有啥不同。我首先想到的是各个角色在胜任力方面可能要求不同。

尝试着列举出了一系列胜任力,发现其实重叠的不少,附件中也有一个小调研(金数据表),很想听听大家的意见。为了找到不同,迫使自己用单一指标的方法来“区分”到底这三个头衔有什么不同,于是产生了下面针对每个角色我认为最重要的胜任力。(记住单一意味着我只给自己一个选项,类似“交流沟通”这样的共性能力都只能被“无情”地去除了。)

选择胜任力时我采用了Workitect公布出来的通用的胜任力字典。我的选择如下:

  • 顾问:概念思维(Conceptual Thinking)—— 从一个整体视角,一定抽象层面或理论高度来寻找有效的解决方案。
  • 教练:赋能他人(Empowering Others)—— 表达对团队取得成功能力的信心,特别是在挑战新的任务方面。 委托重大责任和权力,让团队自主决定如何实现目标并解决问题。
  • 老师:技术专业(Technical Expertise)—— 在技术领域的知识和技能的深度。

【本文是51CTO专栏作者“ThoughtWorks”的原创稿件,微信公众号:思特沃克,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2011-12-12 19:13:27

SAP

2011-12-13 14:22:12

SAP

2017-07-05 07:52:03

敏捷教练IT敏捷

2022-10-27 14:24:45

触敏技术

2017-04-02 09:30:15

机器人驾校机器人教学

2021-09-16 09:38:12

开发项目代码

2013-03-19 10:08:35

软件项目

2009-09-14 09:20:37

2023-04-23 10:37:01

CIO执行顾问

2010-01-07 10:05:51

IT顾问特质

2009-03-12 11:08:00

技术顾问职场杂谈

2013-08-01 12:28:21

SAP

2020-12-10 19:21:42

机器人人工智能教练车

2009-12-31 09:03:51

2010-07-13 10:22:06

SQL Server

2018-03-08 15:00:45

2018-02-28 15:19:43

云计算云计算顾问咨询

2018-05-17 13:59:28

IT顾问

2013-08-27 09:58:57

顾问职业规划

2023-12-15 16:19:29

数字化转型技术改革企业
点赞
收藏

51CTO技术栈公众号