first commit
This commit is contained in:
93
专栏/技术管理实战36讲/00开篇词你为什么需要学管理?.md
Normal file
93
专栏/技术管理实战36讲/00开篇词你为什么需要学管理?.md
Normal file
@ -0,0 +1,93 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
00 开篇词 你为什么需要学管理?
|
||||
你好,我是刘建国,虽然你平生已经认识过很多个“建国”,但其中最关注技术人如何带团队这个话题,并且在“极客时间”上开专栏的,我肯定是第一个。
|
||||
|
||||
你可能会说:“技术才是我的真爱,做管理啊,带团队啊,都不是我要考虑的事儿。”
|
||||
|
||||
嗯!我原来也是这么以为的,因为做管理有一个很重要的因素叫做“意愿”,这说明做不做管理是可以主动选择的,不是吗?
|
||||
|
||||
但是近期我做的一个调研,却让我大跌眼镜,完全颠覆了我的认知。事情的原委是这样的:我统计了最近半年参加“新经理管理图谱”培训的数百名技术管理者,竟然只有 10%~20% 的新经理是主动和上级表达希望做管理的,这也就意味着:超过 80% 的技术管理者,都是在没有明确表达管理意愿的情况下,被公司推到管理岗位的。
|
||||
|
||||
竟然有这么大比例的人都没有做出主动选择,实在匪夷所思。而且,这个数字还不包括那些实际已经在带团队的高级工程师或架构师,他们虽然没有管理的头衔,但已经是一个实际上的 leader。
|
||||
|
||||
我想,你一定可以想象得到,绝大多数技术管理者在刚开始带团队时,对管理该怎么做是知之甚少的,因为他们毫无准备,甚至都不确定自己是不是要在这条路上坚定地走下去。难怪他们常常把管理工作统称为“杂事”,虽有调侃之意,但其不情愿也可见一斑。
|
||||
|
||||
那么,这种技术人被“逼上梁山”做管理的情况,是不是有违常理呢?当我进一步研究了这些技术管理者的公司背景之后,似乎找到了原因所在。在很多传统的企事业单位,要晋升到管理者,需要 5~10 年甚至更久,这使他们有充分的时间去培养一位管理者。
|
||||
|
||||
而在新兴的泛互联网领域,这个时间会缩短为 2~5 年;如果你服务于一家快速崛起的公司,这个时间会进一步缩短为 1~2 年,甚至更短。公司根本就等不到你掌握了管理技能之后再让你带团队,上级会推着你边做边学。事实上,你们的上级极有可能也是这么开始做管理的。所以,如果下周你的上级突然要求你带团队,你可千万别觉得奇怪 ^_^。
|
||||
|
||||
很快你就会发现,对于互联网技术人来说,“带团队”不再是一个可选项,而是迟早都要面对的事儿。做技术和带团队,更像是职业发展的两条腿,而不是完全叉开的两条路。做技术和带团队,更像是职业发展的两条腿,而不是完全叉开的两条路。
|
||||
|
||||
所以,不论你是还在做技术,希望未雨绸缪地对管理有个初步的了解;或是你恰好处在转管理的节骨眼儿上,对怎么做管理感到迷茫;亦或你已经走上管理岗位,对如何应对棘手的管理问题有所困惑,一幅管理者的管理技能全景图都会让你胸有丘壑、从容面对,正如我 10 年前的期待。
|
||||
|
||||
10 年前,在我刚从一个工程师开始带团队时,充满了迷惑和不知所措,当时我多么渴望有前辈可以给我高屋建瓴的指引,提纲挈领地告诉我从技术转做管理,都有哪些要注意的地方,都有哪些事情要做,以及应该怎么操作。对此,我期待了 10 年。
|
||||
|
||||
我带着这样的期待,在百度把 5 人团队带到 150 人的部门,成为百度最佳经理人;带着这样的期待,我把天使轮到 C 轮各阶段创业公司的 CTO 和技术 VP 都做了一遍;带着这样的期待,我先后培养了四五十位新经理。带着这样的期待,最终,我创办了“果见管理工作坊”,专注于对技术新经理的辅导和培养。半年下来,支持了数百计的技术新经理,服务了十多家企业,其中不乏顶级的互联网公司。
|
||||
|
||||
无论是在带新经理的过程中,还是在做新经理培训的过程中,我发现如下三类问题是大家普遍关心的:
|
||||
|
||||
1. 关于 Why 的,比如:
|
||||
|
||||
“老板让我做管理,我到底要不要做呢?”
|
||||
|
||||
“管理这条路是否适合我呢,对我个人发展有什么建议吗?”
|
||||
|
||||
“我不像某某那么适合做管理,我是否还要去尝试呢?”
|
||||
|
||||
……
|
||||
|
||||
2. 关于 What 的,比如:
|
||||
|
||||
“管理到底都需要做哪些事呢?”
|
||||
|
||||
“有没有管理的框架图可以让我按图索骥,做到心中有数呢?”
|
||||
|
||||
“我做得是否足够,我还应该做哪些工作呢?”
|
||||
|
||||
……
|
||||
|
||||
3. 关于 How 的,比如:
|
||||
|
||||
“怎么做团队建设呢?”
|
||||
|
||||
“怎么提升团队凝聚力呢?”
|
||||
|
||||
“怎么做向上沟通和向上管理?”
|
||||
|
||||
“怎么做员工激励?”
|
||||
|
||||
“怎么应对低绩效员工呢?”
|
||||
|
||||
……
|
||||
|
||||
多年来,探讨这些问题的文章多如繁星,但散落天际,我找不到一张“星空图”能把它们系统地关联在一起。纵然上过无数的管理培训,也都是隔靴搔痒,感觉老师在天上说,而我在地上跑。于是,受到“技术管理者”的使命召唤,我希望能用技术人的亲身经历和技术人熟悉的语言,来挑战一下这个管理技能的“星空图”,并以此来阐释技术管理的方方面面。
|
||||
|
||||
无论你是一位“有志”工程师,考虑未来做管理;还是一位“被经理”,被上级不由分说推到管理岗位,希望变被动为主动;无论你是一位即将开始带团队,希望了解管理者应知应会事宜的准经理;还是一位已经开始带团队,希望系统掌握管理方法论的新经理;甚至于你是一位希望交换管理认知、关心新经理培养的老经理,我们都可以在未来的三个月,一起来探讨下面 5 个方面的内容。
|
||||
|
||||
自我倾听。主要围绕“Why”的问题,理顺新经理内心的纠结与彷徨,让你心无旁骛地走上管理之路。
|
||||
|
||||
角色认知。提供给你一个管理工作的“全景图”,以方便你按图索骥地了解管理工作所涵盖的方方面面。
|
||||
|
||||
管理方法。这其中,管理规划、团队建设和任务管理,合称为“管理三部曲”,分别探讨“看方向”“带人”和“做事”的这三个关键的管理内容。
|
||||
|
||||
管理沟通。探讨管理沟通的工具和技巧,并探讨向上、向下、横向等典型沟通场景下的沟通要点。
|
||||
|
||||
管理之路。主要探讨如何积累管理方法论,以及如何成为自己所期待的管理者。
|
||||
|
||||
和技术的确定性思维不同,管理有很多模糊的概念,比如当你开始带团队之后,大家应该怎么称呼你呢?是叫经理?团队 leader?管理者?manager?还是团队负责人?
|
||||
|
||||
为了方便探讨,我姑且把需要带团队的技术人统称为“经理”,而且,文章中提到的“团队 leader”“manager”“管理者”“团队负责人”等概念,如果没有特殊说明,默认都是一回事,都是既需要“带人”,又需要“做事”,也就是对团队和业务都要关心。而非只关注人员成长的人力经理,也不是只关注做事的项目经理。
|
||||
|
||||
好了,无论是已经在带团队的管理者,还是未来或主动或被动将要带团队的工程师,准备好迈出你职业发展的另外“一条腿”了吗?
|
||||
|
||||
最后,我用“颠覆式创新之父”克里斯坦森的一句话,来欢迎你已经或即将带队前行,他在被确诊罹患癌症之后写的《你要如何衡量你的人生》一书中说道:“如果干得好,管理是最崇高的职业之一。没有哪一个职业能像管理一样为他人提供学习和成长的机会,让他们懂得承担责任并取得成绩,以及为团队的成功做出贡献。”
|
||||
|
||||
我坚信,当你学会用“带团队”的思路工作和生活之后,无论你是否拥有“管理者”的头衔,你都将成为身边人事实上的领袖。接下来,就请开启你的领袖之路吧!
|
||||
|
||||
|
||||
|
||||
|
101
专栏/技术管理实战36讲/01多年前的那些工程师都去哪了?.md
Normal file
101
专栏/技术管理实战36讲/01多年前的那些工程师都去哪了?.md
Normal file
@ -0,0 +1,101 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
01 多年前的那些工程师都去哪了?
|
||||
也许是现在,也许是未来,总有那么一天,你会操心自己的职业发展。当你抬起头来,展望自己的职业道路的时候,也许这篇文章可以给你一些指引。
|
||||
|
||||
实际上,我一直希望能够帮技术人整理一个职业发展路径的图谱,让技术人在碰到职业选择困惑的时候,可以看看别人走过的路。而上周的“老知道人”聚会,刚好给了我一个很好的机会,因为这是一个跨越了 10 年的比较完整的“样本集”。
|
||||
|
||||
“老知道人”,是对百度知道早期团队成员的一个称谓,虽然大部分都已不在知道团队,但这并不影响大家对于这个产品以及同事的深厚感情。
|
||||
|
||||
百度知道于 2005 年 11 月正式上线。我正是怀着对这个产品的无比喜爱,以及对百度“让人们平等便捷地获取信息,找到所求”使命的无比认同,于 2005 年 12 月加入知道团队,成为一名后端工程师,因此我对 2005 年~2008 年百度知道的工程师们都非常熟悉。
|
||||
|
||||
刚好就这次聚会,我整理了一下当年这批工程师的职业发展状况,如今大体分布在四个大类的八个方向。
|
||||
|
||||
这四个大类分别是技术类、管理类、创业类和顾问类,接下来我逐个来详细说明。
|
||||
|
||||
一、技术类
|
||||
|
||||
技术类主要包含两个大方向。
|
||||
|
||||
一个方向侧重于“广”,着眼技术的整体性、架构性和业务解决方案,我们姑且称为“架构师”或“首席架构师”。 他们往往是一个产品或服务的技术方案的“总设计师”,他们常见的作品包括社区类服务架构、云服务架构、搜索架构、电商服务架构、O2O 服务架构、数据平台架构等等,每一个产品背后都有一位或几位技术架构师。
|
||||
|
||||
另外一个方向侧重于“专”,着眼于某个专项技术的深度、专业度和精细度,我们姑且称为“某领域技术专家”或“科学家”,比如图像技术、语音技术、机器学习、推荐算法等等。他们往往是一个专业领域里的“武林高手”,他们的作品被广泛应用在每一个专业领域。
|
||||
|
||||
二、管理类
|
||||
|
||||
管理类也有两个不同的方向,即技术管理者和职业经理人。你可以认为职业经理人是技术管理者的更成熟阶段,但我更倾向于认为这是两个不同的选择。
|
||||
|
||||
技术管理者,这个方向很自然,就是从工程师到技术团队的一线经理,再慢慢做到部门经理等二线经理,然后是某个大技术体系或整个技术部的技术副总裁,如果还包括产品、设计等所有“产品交付”类团队,就成为了一个常规意义上的 CTO,但总体上,都是技术管理者。
|
||||
|
||||
另外一个方向是职业经理人。之所以叫职业经理人,是他不限于管理技术类团队,往往负责的是一个完整的业务,很像是这个业务的 CEO,有些公司也会叫 GM(general manager)。这个角色并不限定在具体一个业务,还可以根据公司需要去负责一个新业务,迁移性比较强,比较接近我们常说的“职业经理人”。这样的管理者会关心一个业务经营的方方面面,但本质还是公司高管,在公司整体框架下工作。
|
||||
|
||||
三、创业类
|
||||
|
||||
创业类对于技术人来说,也有两个方向。
|
||||
|
||||
一个方向是作为创始人牵头创业,做领头羊。创业成功后就成为我们所说的“企业家”,像李彦宏、马化腾、周鸿祎等,这都是技术人牵头创业的典范。当前人工智能、大数据、区块链、云服务这些技术方向的大热,也催生出很多技术出身的 CEO,在自己的技术领域里开疆拓土,挥斥方遒,神策数据的 CEO 桑文锋就是我们“老知道人”在这个方向上的佼佼者。
|
||||
|
||||
另一个方向是作为技术合伙人或技术高管全盘负责公司的技术,以技术管理为公司“安邦定国”。几乎每一个成功的创业公司,都有这么一个强有力的角色,比如互联网第二梯队的 TMD 中, 头条(T)的杨震原、美团(M)的穆荣均、滴滴(D)的张博,都是这个方向上的优秀代表。
|
||||
|
||||
而且可以小小自豪一下的是,他们都是曾经的老百度人,其中荣均还是百度知道的元老之一。显然,这个方向上的成功案例不仅于此,大部分独角兽的公司背后都有一个强有力的技术高管。
|
||||
|
||||
你可能会问,这个技术合伙人的方向,和技术管理者的方向有什么区别吗?看上去都是“技术高管”。但区别其实还是很大的,主要在于:你是从公司早期就共同创业做到高管的,还是你只是在一家比较成熟的公司做高管的?这是两条很不同的路。
|
||||
|
||||
其中,前者的核心是共同创业,这里我列举的都是创业比较成功的案例,是为了方便你理解和认知,而现实中大部分的创业都是尚未成功的,所以大部分技术合伙人面临的是创业团队的压力和不确定性,他们在大部分时间内都不是技术高管,而是共同创业者;但后者,较成熟公司的技术高管则不同,他们大部分时间都是在做技术管理,工作方式、方法和创业公司差别是很大的,所以这其实是非常不同的两个职业方向。
|
||||
|
||||
你可能还会问,为什么要把创业者和技术合伙人区分为两个方向呢?他们不都怀着创业的心态吗?我想说,我分开来讲的原因是这两个角色对人的要求的差异是相当大的,因为他们的职责差异很大,所以他们的“技能清单”差异也很大,因此我将其分为两个方向。
|
||||
|
||||
四、顾问类
|
||||
|
||||
顾问类的两个方向离得有点远。
|
||||
|
||||
一个方向是投资顾问,也就是做投资人,有做投前的,也有做投后的,基于对一个创业团队和项目的完整判断,从外围以资本运作和投后服务来支持创业公司发展。他们在做投资人之前,往往都有着相当丰富的企业经营管理经验、宽广的视野和敏锐的洞察力。比如百度风投的齐玉杰、清流资本的王梦秋和陈韫敏,之前都是百度的高管,都曾经直接或间接管理过百度知道团队,他们也都曾经是百度的工程师,典型的技术人。
|
||||
|
||||
另外一个方向是管理顾问,也就是提供培训、咨询服务,偏人力发展和团队建设。这个方向是通过支持管理者和 HR 来支持公司的发展,往往以多年的管理经验、管理理论、教练技术和培训经验为依托。目前,这个方向的人是最少的,好像只有我在做。而且,1 年前,我还是创业公司的技术高管,而 5 年前,我是百度的一名部门经理。
|
||||
|
||||
上面,就是 10 年前的“老知道人”,在 10 年后的职业发展情况。你可能会问,除了上述 8 个方向,还有没有其他的发展路径呢?答案是有的,比如技术网红、技术媒体人,以及各种断崖式转行:专职理财、继承家业、全职奶爸奶妈、周游世界等等,这些情况太偶然,很难借鉴,所以不在我们的探讨范围内。
|
||||
|
||||
你是不是会好奇,这 20 个人的分布情况会是什么样的呢?下面,我们来看看各个方向的占比:
|
||||
|
||||
|
||||
|
||||
“老知道人”发展方向分布
|
||||
|
||||
综合这些数据我们不难发现如下三个特点:
|
||||
|
||||
整体分布情况比较分散,大家 10 年后都有了自己的选择。
|
||||
|
||||
技术管理者和创业公司的技术合伙人相对集中,两个方向加起来超过一半。
|
||||
|
||||
10 年后仍坚持做技术的比例比较低,在 20% 左右。
|
||||
|
||||
当然,这个“样本集”用于说明整个互联网领域技术人的发展情况,显然是不能完全代表的。但是这也可以在一定程度上给你一些感性认知,供你参考。
|
||||
|
||||
你可能会问,不同的发展方向,需要做哪些方面的准备和积累呢?对此,我先展示一下各个发展方向上的“技能清单”,这个技能清单都是“通常来说”需要具备的,并不能代表所有情况:
|
||||
|
||||
|
||||
|
||||
八大方向技能清单
|
||||
|
||||
上面这些“技能清单”,用的都是很大的词,听起来可能有些笼统,我理一下大体的逻辑。
|
||||
|
||||
开始,你作为工程师,需要有很好的技术实操能力,这是作为工程师的职业素质。慢慢地,随着你能做的事情越来越多、越来越大,你会提升整体架构能力,成为一名架构师。而如果你对某个专业领域的技术越来越专精,你会成为一名技术专家或科学家。
|
||||
|
||||
当然,你也可以不断拓展自己项目管理能力和带团队的能力,这样你会成为越来越高级的技术管理者,也可以去创业公司做技术合伙人。当你越来越关注行业发展、商业逻辑、公司经营,就慢慢拥有了职业经理人和公司创始人的视角;当越来越关注资本运作和资本产生的价值,就会从投资人的角度去看待各行各业和整个社会。
|
||||
|
||||
这里我是按照视角的迁移和能力的扩展来阐述整个过程的,但是作为每个人的职业发展,却并不需要完全沿着这个过程,也并没有越后者越高级的说法,最终你会停留在自己喜欢和认同的角色上,那个就是最好的。
|
||||
|
||||
但是,无论你走哪条路上,你都会发现有些能力是共通的,比如规划、带人、沟通、执行等管理能力覆盖了全部 8 个方向。
|
||||
|
||||
因此,这里你还需要区分“技术管理能力”和“技术管理岗位”这两个概念。你可能出于兴趣、机遇等各种原因不会去选择做“技术管理岗位”,但是,“管理”作为一项综合能力,是你未来的职业发展所不可回避的,至少你都需要和管理者合作。只不过因为你的角色不同,需要掌握的程度不同。
|
||||
|
||||
总之,对于技术人来说,无论你是否做技术管理岗,你所有的职业发展,都会围绕着技术和管理这两条腿在走路,一条腿是走不远的。
|
||||
|
||||
所以,你现在知道多年前的那些工程师,是如何迈着两条腿走向远方的吗?
|
||||
|
||||
|
||||
|
||||
|
117
专栏/技术管理实战36讲/02我要不要做管理呢?内心好纠结!.md
Normal file
117
专栏/技术管理实战36讲/02我要不要做管理呢?内心好纠结!.md
Normal file
@ -0,0 +1,117 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
02 我要不要做管理呢?内心好纠结!
|
||||
上一篇文章,我们探讨了技术人常见的职业发展方向,不难看出,在做了几年技术之后,大部分技术人会把“做管理”作为一个重要选项来考虑,甚至在很多时候,你的上级会推着你带团队。你是否正处在这样一个阶段?是否犹豫过要不要做管理呢?
|
||||
|
||||
在十来年的管理工作中,我常常被工程师这样询问:“我适不适合做管理呢?你对我有什么建议吗?”每当此时,我都会反过来问他一个问题:“能否先告诉我,做管理对你来说意味着什么呢?你觉得它能给你带来什么?”
|
||||
|
||||
我当然不是在质疑他,只是想让他去反思自己“做管理”的初衷。因为大部分新经理,即使都已经踏上了管理之路,却并没有认真审视过自己的初衷。而这个问题是非常重要的,因为它不仅决定了你能在这条路上走多久,还决定了你能走多远、走多好,甚至走得是否开心。所以,我会第一时间提出这个问题来。
|
||||
|
||||
在我做过的访谈中,以下四类说法是最为常见的:
|
||||
|
||||
第一类:不得已的选择。典型说法有:
|
||||
|
||||
“我对技术没有热情,也没有技术特长,所以只能做管理。”
|
||||
|
||||
“做技术又不能做一辈子,很多前辈都转管理了,我也要转。”
|
||||
|
||||
“没有办法,公司发展太快了,老板要求我带团队。”
|
||||
|
||||
第二类:别人眼里的成功。典型说法有:
|
||||
|
||||
“如果能做到公司高管,别人都会认为我是一个优秀和成功的人。”
|
||||
|
||||
“能够做管理带团队,这样在家人眼中会很风光。”
|
||||
|
||||
第三类:不辜负组织的期待。典型说法有:
|
||||
|
||||
“上级说我适合做管理,我不能辜负他对我的期望。”
|
||||
|
||||
“公司需要我带团队,这是公司对我的信任,我一定得做好。”
|
||||
|
||||
第四类:对做管理的主观遐想。典型说法有:
|
||||
|
||||
“不用凡事亲力亲为,安排下级去做就好了,应该会轻松些。”
|
||||
|
||||
“做管理越晋升越轻松,你看高管都不坐班。”
|
||||
|
||||
那你对于这个问题的回答,会对应上面四类中的哪一类呢?
|
||||
|
||||
我想说,无论是上述四类中的哪一类,都很难让你在管理之路上走很远。因为上面的四类说法都属于“外驱力”范畴。如果你因为这样的“外驱力”而选择了管理,时间一长你就会觉得管理工作越来越烦人,而且并不如自己所期待的那样风光,甚至会怀疑自己当初是否选错了路。
|
||||
|
||||
其实,你并不见得是选错了路,只不过之前的选择都是基于外部的推力和诱惑所进行的决策,而外力很多时候并不是你能掌控的。
|
||||
|
||||
事到如今,是该考虑你自己的内在动力和真正诉求的时候了。
|
||||
|
||||
你可能会说:“我一直都清楚自己的诉求啊,哪个发展得好、回报丰厚,我就选哪个。这还有什么好探讨的吗?”事实上,每条职业道路上都有非常出色的榜样,关键是你能否在你选择的道路上也那么优秀呢?这个问题的答案,恰恰就建立于你内心的渴望和意愿上。况且,意愿也是公司考察管理候选人是否适合做管理的重要因素,所以这个问题不可回避。
|
||||
|
||||
你可能会追问:“我都还没有做过管理,或者我只是刚开始做管理,我怎么判断这是否是我的真爱呢?”
|
||||
|
||||
下面,我通过以下三个重要问题,来帮你做个判断。
|
||||
|
||||
第一个重要问题是关于“管理的价值观”的,即你是否认同管理的价值呢?你可能会疑惑,这会成为一个问题吗?我很肯定地告诉你,会。很多新经理的上级会跟我诉苦,说他们的新经理不认同管理的价值,常常会跟他们抱怨,主要表现是:
|
||||
|
||||
认为招聘面试、辅导员工、向上汇报、开会沟通、流程梳理、资源协调、进度推动、绩效评估等大部分管理工作,都是琐碎的“杂事”,很难从这些工作中获得价值感和成就感,甚至还对于这些工作挤占了写代码的时间而不满。
|
||||
|
||||
认为经理是给高工和架构师打下手的,职责就是支持好架构师的工作,所以比较郁闷。
|
||||
|
||||
认为管理的工作不如技术工作有价值,通过技术手段来解决问题才是最酷的事情。
|
||||
|
||||
你是否也会这么认为呢?
|
||||
|
||||
即使有很多人都认为你适合做管理,而如果你自己不认为管理是有价值的,你是不会开心地长久做下去的。
|
||||
|
||||
第二个重要的问题是,你是否对管理充满热情,并享受这些工作呢?你可能会问:“我还没有做过经理啊,怎么知道有没有热情呢?”而事实上,做很多管理工作并不需要经理的头衔,下面的这些问题供你参考:
|
||||
|
||||
你是否主动地向自己的上级了解过团队的工作目标呢?
|
||||
|
||||
你是否主动关心过新同事该怎么培养,以及如何更好地帮助他们成长呢?
|
||||
|
||||
你是否享受去负责一个大项目的协调和推进?它的成功发布是否会给你带来强烈的成就感呢?
|
||||
|
||||
你是否思考过什么样的流程和机制可以应对团队工作中的那些疏漏呢?
|
||||
|
||||
如果你的答案都是“否”,也没有关系,重要的是,你看到这些问题,是饶有兴趣,还是非常抵触呢?如果还是“否”,那你可能此时还不适合做管理。
|
||||
|
||||
第三个重要问题是,你是否看重在管理方面的成长呢?每位管理者,都是从技术骨干或业务骨干开始起步的,在此之前并没有太多管理方面的学习和积累,这意味着你有很好的管理可塑性,同时也意味着你有太多的东西需要学习和训练。
|
||||
|
||||
做管理要扩充的认知和能力很多,以至于我们整个专栏都会探讨这些问题。这里我先列举几个基本的认知:
|
||||
|
||||
1. 更大的责任。很多人会把晋升到管理职位,理解成更大的权力和更高的地位,认为经理对于员工是处于掌控和支配地位的。也许过去在某些领域的管理者的确如此,但在互联网公司里的管理者,这样的管理哲学会遇到很多困境。在互联网领域,管理者带一个团队,更多是意味着要承担更大的期待和责任。即便有时看上去有一定权力,但归根结底,还是为了更好地实现团队目标,基本体会不到行使权力的快感。这是不是如你所期待呢?
|
||||
|
||||
2. 更立体的视角。在做工程师的时候,只要做好上级交代的任务就好了。而一旦做管理,为了带好整个团队,就需要考虑上级、下级、平级的期待和诉求,而且不能只是关心“眼前”,还得关心“从前”和“以后”,提升看待问题的系统性。这是你喜欢的能力吗?
|
||||
|
||||
3. 更灵活的思维方式。多年的技术工作训练,你一定有很强的确定性的思维方式,讲究界限清晰、对错分明、言出必行、不出差错,往往靠谱就是你的代名词;而很多管理工作却是充满着不确定性的,有些工作的执行边界也是模糊的,甚至是非对错都很难界定清楚。在各种不确定因素中,却要去追求一个明确的目标,这对于很多新的技术管理者来说,思维方式会受到很大冲击。你想扩展你的思维方式吗?
|
||||
|
||||
读到这里,你也许会问:“看上去都是挑战和要求,那我能得到什么呢?”
|
||||
|
||||
事物都是具有两面性的,上述的挑战和要求也会给你带来成长与收获。接下来,我和你说说能收获什么。
|
||||
|
||||
首先,你到了一个更大的平台上,你的能力和视野将得到大幅度提升。这会给你带来明显的成长感。
|
||||
|
||||
其次,你不但能力变强了,你还有团队了,你能搞定更大、更复杂的事情,做出更大的成绩。这会带给你更强的成就感。
|
||||
|
||||
再次,你可以带着团队做出越来越多的成就,你的团队也越来越优秀,团队成员都得到了成长,你甚至还会影响到合作团队。你的影响力显著提升了。
|
||||
|
||||
最后,你的能力、成绩、影响力全面提升,你得到了更多的精神和物质的回报。你所有的付出、成长和积累,都将或早或晚地换回等值的回馈。你的获得感也将得到满足。
|
||||
|
||||
所以,关于你的初衷、你的投入、你的成长以及你的回报之间的逻辑,你是否看清楚了呢?
|
||||
|
||||
如果说你前面问我“适不适合”,主要是指“你是否可以很好地胜任”,以及“能否拿到自己想要的回报”。那么,此时你就知道要回答好这两个问题,是需要首先回答另外两问题的,即:这个选择是否更符合“你的初衷”,以及是否更能激发“你投入的意愿”。因为,这两个问题里蕴含着你的价值观、你的核心诉求,以及你的擅长和热爱,这些底层的动力,正是你面对挑战、走向卓越所需要的最重要的东西。
|
||||
|
||||
正因如此,丹尼尔·平克在《驱动力 3.0》一书中有说:“服从让我们撑过白天,而投入才能让我们撑过夜晚。”这告诉了我们一个很简单的事实:外驱让我们可以做好本职工作,而内驱才能让我们成就卓越。
|
||||
|
||||
这具体到我们今天的话题就是:你都开始考虑做管理了,只是按部就班地做好工作,已经不再是你的诉求了,不是吗?
|
||||
|
||||
倘若你恰好正在扣响管理之门,你认为是否有必要去审视一下自己内在的动力呢?
|
||||
|
||||
当然,管理之路很长,一时想不清楚、看不明白也不用担心,我们专栏一共有 36 篇文章,在这期间你会有充分的时间去雕琢一个属于你自己的管理艺术品。
|
||||
|
||||
你准备好和我一起探讨了吗?
|
||||
|
||||
|
||||
|
||||
|
123
专栏/技术管理实战36讲/03哪些人比较容易走上管理岗位?.md
Normal file
123
专栏/技术管理实战36讲/03哪些人比较容易走上管理岗位?.md
Normal file
@ -0,0 +1,123 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
03 哪些人比较容易走上管理岗位?
|
||||
也许你早就决定做一名管理者,又或者你刚刚有这个打算,不管哪种情况,你是否已经和你的上级交流过这个问题呢?在我调研过的几百位新经理中,只有百分之十几的比例和上级表达过管理意愿,而我自己培养的几十位新经理中,明确表示自己想做管理的,大约只有 20% 左右,这个比例很低。虽然我可能没法立刻满足他们,但在有合适岗位的时候,我的确会优先考虑他们,因为对于做管理来说,个人意愿很重要。
|
||||
|
||||
不过,一个有意思的情况是,最顺利走上管理岗位的,却不一定是这些诉求最明确、准备最超前、表白最早的 20%。这是为什么呢?在做咨询的时候,我也常常会收到类似的困惑。比如:
|
||||
|
||||
“团队里我的资历最老,对业务最熟悉,为什么上级提拔的不是我?”
|
||||
|
||||
“我是上级最倚重、最信任的一个,经常受到表扬,为什么上级选他做 leader 呢?”
|
||||
|
||||
“我一直想做管理,但是团队里没有管理的坑儿了,要不要换个工作?”
|
||||
|
||||
……
|
||||
|
||||
上面这些人没有被第一时间提拔,是做管理的天资不够吗?显然不是。这引发一个值得思考的问题:到底什么样的人更容易走上管理岗位呢?
|
||||
|
||||
下面我们一起来聊聊。
|
||||
|
||||
中国古人有大智慧,对于促成一件事所需要的外部因素,他们把它概括为“天时地利人和”。什么?你认为谈论做管理,扯上“天时地利人和”太虚无缥缈?别急,先让我说完。
|
||||
|
||||
一、“天时”
|
||||
|
||||
做管理的“天时”,其实就是机会、时机、大环境、时代背景。
|
||||
|
||||
经常有人跟我抒发内心的郁闷,“我一起毕业的大学同学,很多都已经做管理了,职位和薪水都比我高,当时他们学习并不比我强,blah,blah”,不甘心和不理解溢于言表,感觉自己受到了不公平待遇。而我想说的是,毕业的时候你选择了什么样的行业和企业,就决定了什么样的机会和可能。
|
||||
|
||||
十几年前,我很多优秀的研究生同学,毕业后去了微软、IBM、摩托罗拉等世界顶级公司,或者因为户口去了一些国企和事业单位,去互联网公司并不是大家的首选。
|
||||
|
||||
但近十几年变化最大、发展最快的反而是互联网行业,反而是那些在互联网行业的同学,随着行业和企业的快速发展,能力和职位都提升特别快,不少同学已经成为中大型公司的高管,带着几百人、上千人的团队,远远超过了在外企和国企同学的发展速度。
|
||||
|
||||
当然,我这里并没有去探讨成功或失败的问题,在外企和国企的同学如果拿到了他们当初想要的,他们一样也是很成功的。
|
||||
|
||||
我只是想说,如果你要做管理,最好选择那些发展快的行业和公司,这意味着更多的机会。当然更多的机会也意味着更多的挑战,如果你希望工作得舒服轻松一些,依然可以去稳定的行业和企业工作,但在稳定的行业要走上管理岗位,可能就需要漫长的等待了。
|
||||
|
||||
那么,是不是变化越快就越适合做管理呢?
|
||||
|
||||
相信经常有人对你说,去创业公司吧,小公司机会多,锻炼的能力也更加全面。如果你是因为其他原因去初创公司,我不做评判;但如果你的初衷是想做管理,那我可以明确告诉你,天使轮、A 轮这样的早期公司,大多处于生存期,还没有上规模,而没有规模的公司并不需要你去做管理,所以你很大概率会失望。
|
||||
|
||||
而且,管理是需要长期积累的。百度曾经有个不成文的规定,技术岗位最优秀的员工可以半年晋升,但管理岗必须在当前职位干满一年才能晋升,可见对实战经验的积累是多么重视。对于初创公司来说,能否再活一年都不好说,更别提让你稳定积累了。而你如果频繁更换公司,对管理能力的提升则更为不利。
|
||||
|
||||
所以,去能积累的公司做管理,会是更合理的选择。
|
||||
|
||||
另外,还有一些机会是偶然的。比如我团队一个同事的外语特别好,在搭建国际化团队的时候,他就被选中作为负责人;还有另外一个同事,因为他有机器学习背景,在新组建一个策略团队的时候,他就顺理成章成为了该团队的 leader。
|
||||
|
||||
这些以自身独特优势为前提的因素,虽然看起来更像是“地利”,但其实更加受限于时机。所以我想告诉你,一个人走上管理岗位有很多“机缘”,你可以审视一下,你所在的公司和团队可能产生出哪些新的机会。
|
||||
|
||||
当然,这里我并不是鼓励大家跳槽时只去选“天时”,因为除了关注“天时”之外,“地利”和“人和”也很重要,需要综合评估。
|
||||
|
||||
二、“地利”
|
||||
|
||||
做管理的“地利”,就是你的优势、能力,以及你所负责的工作内容。
|
||||
|
||||
所谓优势,都是基于特定的工作内容和工作任务而言的,抛开具体工作场景泛泛地谈优势和能力没有意义。那么对于技术人来说,从事什么样的工作内容,以及具有哪些能力和优势对走上管理岗位有帮助呢?
|
||||
|
||||
你可能会说,大家都是写代码的,要说技术能力对晋升有影响很容易理解,工作内容还能影响晋升?我想说,是的,而且很有影响。我十年来带技术团队的经历中,发现负责如下这些工作内容的工程师,更容易成为管理者:
|
||||
|
||||
第一类是负责最全局的模块,核心是“广”。
|
||||
|
||||
每一个团队的业务,都会分成很多模块,总会有那么几个模块是事关全局的,也是跟大家关联最多的,比如提供所有的服务接口、做所有的数据组装和呈现、产品功能的实现等等。
|
||||
|
||||
这样的工作内容,使得负责的工程师很快锻炼出全局的视野、积极的沟通协调能力,并和很多人建立起合作关系。做得好的话,很快就可以成为一个团队的工作核心。
|
||||
|
||||
因此,很多技术人是这样走上管理岗位的,他们往往管理成熟度也高,成功的概率很大。
|
||||
|
||||
第二类是负责最核心的技术模块,核心是“深”。
|
||||
|
||||
这个就容易理解了,掌握着团队最核心、最重要、最有技术含量、最能体现团队价值的模块的工程师,是团队里的骨干,不可或缺的技术核心,容易得到上级重视去承担重任。他们往往影响力比较大,所以容易走上管理岗位,不过常常是被动的。
|
||||
|
||||
有一点需要注意的是,这类工程师即便能走上管理岗位,很多管理的意识和能力还是需要修炼的,因为他不像第一类天然就有锻炼全局视野和管理技能的机会。但无论如何,他们也是容易脱颖而出的。
|
||||
|
||||
所以你看,负责的工作内容是否全局和关键,是会影响你能多快地走上管理之路的。
|
||||
|
||||
你可能会有疑问:“我没有负责这样的模块,是不是就没有机会了呢?”当然不是。如果你主动去了解技术和业务的全局,并主动争取做一些大型项目的负责人,你就具备了做管理的“地利”,前提是你先认识到这一点。
|
||||
|
||||
三、“人和”
|
||||
|
||||
做管理的“人和”,就是你能否得到他人的支持。
|
||||
|
||||
那么,要得到哪些人的哪些支持呢?一般来说,你需要四类支持:
|
||||
|
||||
|
||||
|
||||
管理者的支持系统——“人和”
|
||||
|
||||
第一类,为你提供机会、平台和资源的支持。一般是你的上级,他们是否支持你做管理非常重要。
|
||||
|
||||
第二类,为你提供陪伴和共同成长的支持。一般是和你平级的管理者,尤其是那些你愿意与之持续交流、切磋管理问题的伙伴。当然也可以是之前的同学和朋友,还可以是一些管理社群。总之,你可以根据自己的情况和喜好来看看,谁可以做你的管理伙伴。
|
||||
|
||||
第三类,为你提供指导和前进的方向。一般是你的导师、指导人、管理教练或上级。你可以设定你认可的管理榜样,多和他交流,多听听他的看法和意见,这会让你的管理之路顺畅很多。
|
||||
|
||||
第四类,为你提供情感支持,让你勇于面对困难和挫折,在管理之路上走得更远。一般来说,你的家人和朋友,可以担当这样的角色。
|
||||
|
||||
盘点以上四类人,并寻求他们的支持,尤其是稳定的支持,就构成了你做管理的“支持系统”,满足了你的“人和”。
|
||||
|
||||
这样,“天时”“地利”“人和”这三类外部因素都具备了(如下图),你自然可以更顺利地走上管理岗位。
|
||||
|
||||
|
||||
|
||||
管理之路的外部因素
|
||||
|
||||
但你也许会问:“天时、地利、人和,我都不具备,我是不是就不能做管理了呢?”
|
||||
|
||||
淡定,我们这篇文章探讨的是:什么样的人容易走上管理岗位,我可从来没有说过不具备这些条件就做不了管理了啊。你不信的话,我跟你说说我是怎么开始做管理的。
|
||||
|
||||
十年前,我是一名普通的服务端工程师,但我做工程师的时候,就认定自己要成为一名管理者的。我的上级是一位刚刚晋升的经理,而我们团队只有 5 个人,显然不需要第二个经理,于是,我晋升经理这事看起来是没有机会的。
|
||||
|
||||
更令人绝望的是,我们的部门经理认定我不适合做管理,他认为我是一位很典型的工程师,因为我曾经连续获得部门的“最佳质量工程师”的称号,似乎写高质量代码才是我的优势。于是,做管理的“天时”“地利”“人和”,我一样都没有,我是不是该死了这条心呢?
|
||||
|
||||
事实是,我并没有在意这些情况,我依然会在编码工作之余,去关心项目的流程该怎么改进,团队合作的机制该怎么建立,新员工入职该怎么培养,团队的氛围该怎么建设……虽然我之前并没做过这些工作,上级也不会因此就给我多发薪水。
|
||||
|
||||
但是我还是用心去做了,而且越做越拿手,团队里的同事和上级经理也慢慢认可了我的贡献和价值,部门经理也扭转了对我的看法,于是他把我的直接经理调去负责更大更有挑战的业务,提拔我来负责我们团队。从此,开启了我的十年管理之路。
|
||||
|
||||
所以你看,想被提拔为一个管理者最好的方式,就是你首先成为一个实际上的管理者,我们常常把这样的晋升理念叫“既定事实”,而这种理念在互联网行业里被广泛认同。
|
||||
|
||||
所以,在审视你的“天时地利人和”之余,你准备好先成为一个实际上的管理者了吗?
|
||||
|
||||
|
||||
|
||||
|
103
专栏/技术管理实战36讲/04我要不要转回去做技术呢?.md
Normal file
103
专栏/技术管理实战36讲/04我要不要转回去做技术呢?.md
Normal file
@ -0,0 +1,103 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
04 我要不要转回去做技术呢?
|
||||
由于工作关系,我经常有机会和转管理前后的准经理或新经理聊天,并经常会问他们这样一个问题:“经历从工程师到团队 leader 这个转变,你最大的感受是什么?”
|
||||
|
||||
有人会一脸无奈地对我说:“管理的事儿太杂,都没时间写代码了,越来越心虚……”
|
||||
|
||||
有人语重心长地告诉我:“做管理最大的挑战是,要舍弃技术,特别难。”
|
||||
|
||||
有人会抬头反问我:“管理和技术到底该怎么平衡?”
|
||||
|
||||
有人会故作轻松地笑道:“突然不写代码了,感觉吃饭的家伙没了,哈哈。”
|
||||
|
||||
有人则会满心忧虑:“管理工作太琐碎,感觉离技术越来越远,现在特别担心个人发展。”
|
||||
|
||||
甚至,还会有人忿忿地跟我说:“管理是一个有违人性的事情,自己的技术专业性越来越差,但是却要带领整个团队。”
|
||||
|
||||
诸如上面种种说法,如果我告诉你,我接触过的上百位技术新经理中,有大约三分之二的人都有类似的担忧和反馈,你会不会大吃一惊?
|
||||
|
||||
如果你恰好正在经历这个阶段,你对于个人角色转变的最大感受又是什么?你又如何看待技术和管理间的“冲突”呢?会不会也像我的几位学员那样或忧虑,或愤慨?最后只能无奈地说:“反正想不明白,就多投入一些时间来兼顾技术和管理吧!”
|
||||
|
||||
然而,“两者兼顾”并不能真正解决问题,要解决这些问题,我们得首先来看看问题的真正根源是什么,然后才能对症下药。回想一下上面我列举的那些烦恼,它们有什么共同点呢?
|
||||
|
||||
我认为大致可以归类为以下三种情况:
|
||||
|
||||
转管理之前没有仔细了解过管理。技术人员,常常会沉浸在代码或者技术细节当中,在职业发展方向的思考上,整体偏被动。他们往往是被领导推到管理岗位上去的,而在此之前对怎么做管理并没有深入了解。因此对很多技术新经理来说,管理几乎是一个全新事物。在全新事物面前,因为无法掌控而感到或恐慌、或焦虑就在所难免了,时不时就会冒出一个念头:万一做不好怎么办?退路在哪里?
|
||||
|
||||
才开始做管理,还无法靠管理“安身立命”。至少在他们自己心中,管理能力并不能让自己安心,更不能让自己依靠,就好像还没有完全驯服的野马,还不确信能骑好,想来这也是人之常情。
|
||||
|
||||
认为技术才是自己的“大本营”。由于技术作为自己依存的资本,在过去的工作中已经得到了很好的证明,因此非常值得信赖。所谓“成功路径依赖”,每个人都大抵如此,尤其是做事特别讲究精确与可靠的技术人,自然在所难免。
|
||||
|
||||
以上三个共同点归结到一起,恰好如实反映了新经理此时的状态:“患得”“患失”。当然,这里没有贬义和批评的意思,只是说明一种纠结的心情。“患得患失”出自《论语》,原文是“其未得之也,患不得之;既得之,患失之”,翻译成白话就是“还没有得到的时候,担心得不到;而得到了之后,又担心失去”。
|
||||
|
||||
新经理的状态,从对自己安身立命的安全感角度来看,可以说是一种青黄不接的状态。他们对于做管理,还没有摸到门道,不知道该怎么搞定,经常出现一些让自己不知所措的状况,倍感心焦;而之前已经熟练掌握的技术能力,因为在上面花的时间越来越少,感觉正在离自己而去,怎不令人烦恼呢!
|
||||
|
||||
既然,我们已经知道了“病根”,那么怎么祛除烦恼呢?我这里有三个药方,每一个都会缓解烦恼,如果三管齐下,应该会神清气爽了吧!
|
||||
|
||||
第一个药方,专门针对“患失”来开。
|
||||
|
||||
作为一个做过技术 VP 和 CTO 的所谓“过来人”,我可以负责任地说,做技术管理,你并没有放弃技术,而且也不能放弃技术,放弃了技术是做不好技术管理的,你只是在一定程度上,放弃了编码而已。那么,都没时间编码,怎样才能做到不放弃技术呢?
|
||||
|
||||
首先,把技术提到更高视角来看待。做技术的时候,把技术做好就是最大的目标;而做了管理之后,你会把技术作为一个手段来看待,看它究竟能为目标带来什么。但这并不意味着你就不再关心技术,只是关心的层次不同了,你开始需要借助每个人的技术能力去做更大的事情了。
|
||||
|
||||
这很像在学习组装电脑,即便已经不需要关心主板、内存、CPU 的内部运行逻辑,但你还是要很清楚它们的功能是什么,接口什么样,以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏,也得清楚在整台电脑中,哪个部件可能会是短板,等等。所以,技术转管理并不意味着不关心技术,只是更关心更大的目标和整体结果了。
|
||||
|
||||
其次,换一种学习方式来掌握技术。你要深刻地认识到,亲自写代码固然是很好的学习技术的方式,但是作为 leader,你需要快速掌握更多的技术,并且快速判断该如何搭配使用,所以你一定得有更高效的学习方式才行。这里我介绍三个行之有效的做法:
|
||||
|
||||
建立你的学习机制。你可以想想在团队内建立什么样的学习机制,可以帮助你借助团队的力量来提升技术判断力,并结合自己的情况来创建。
|
||||
|
||||
请教专家。在了解某一个领域的情况时,借助你的平台,找你能找到的最厉害的专家高手进行请教,他们之所以成为高手,一般都能给出高屋建瓴、醍醐灌顶的认知。
|
||||
|
||||
共创。在这个知识型工作者的时代,和自己埋头思考相比,共创成果往往会出乎你想象,特别能增长见识,你可以看看在团队中如何建立共创机制。
|
||||
|
||||
对于要快速提升技术视野来说,以上三个方式,比看书或写代码都更加高效,你可以选择适合自己的方式。
|
||||
|
||||
最后,关于“患失”,还有一个视角,如果你是真心热爱技术,擅长用技术的思路和方案解决问题,你可以做技术型管理者你可以做技术型管理者。做管理主要看结果,对于手段并没有一定之规,你完全可以有自己的独特风格。
|
||||
|
||||
你是否发现,有的技术管理者已经带几百人的团队了,还是一副技术极客范儿?有的管理者擅长带人,有的管理者则执行力特别强,而有的管理者资源整合能力特别强,等等,不一而同,只要和自己团队的核心职能具有一致性就好。如果技术本身就是你的优势,你完全可以结合自己的兴趣和优势,打造出自己的管理风格。
|
||||
|
||||
以上就是我开出的第一个药方:无论从哪个方面讲,你都并没有放弃技术,只是换了一种方式去学习和运用技术。所以,你不会失去什么,也不需要“患失”。
|
||||
|
||||
第二个药方,专门针对“患得”开出。
|
||||
|
||||
这里的“患得”其实是患“不得”,那么怎样才能不再担心做不好管理呢?
|
||||
|
||||
首先,做管理对个人成长和个人发展来说,不会失败。因为管理总体上是一项修炼,只要你持续不断地实践、练习,你的造诣就会越来越高,最后你一定可以胜任某个规模或某个职能的团队。我们通常所谓的“不胜任”,只是说不匹配,而不是说你就完全做不了管理。而且,管理是很个性化的工作,你完全可以使用自己擅长的方式,去达成管理效果。
|
||||
|
||||
其次,一线技术管理者,即便“做不好”也并非没有“回头路”。刚刚从工程师岗位转到管理者岗位时,离技术很近,如果尝试下来,感觉管理工作确实不是自己想要的,那么,回过头来继续做工程师,几乎是没有门槛的。所以,如果当下不知道自己适不适合做管理,不如全力以赴去尝试一段时间,你其实还有充足的时间来慢慢做这个决定,不需要有后顾之忧。
|
||||
|
||||
最后,做管理所积累的能力,完全可以迁移到做“技术带头人”或“技术 leader”这个角色上。所以,你都不用担心管理的工作会白做,或者本来可以做技术的时间被耽误了。因为,即便你再回头去做工程师,也需要练习去做高级工程师或架构师,需要尝试去负责一个完整的技术方向,此时,你做管理时锻炼的全局视野、规划能力、结果导向意识、项目管理方法、沟通协调能力等等,都会派上用场。
|
||||
|
||||
所以,我开出的第二个药方就是:你一定会有所得,会在做管理过程中有丰富的收获,既然一定能“得到”,所以不需要去“患得”。
|
||||
|
||||
第三个药方,有点猛,叫做“认清现实”。
|
||||
|
||||
如果你把“编码时间减少”叫做放弃技术,那我得告诉你一个残酷的现实,无论你做不做管理,这事都不可避免。现实是,你要么做技术管理,用更高的视角来看待技术;要么你继续做工程师,也要用更高的视角去看待技术。
|
||||
|
||||
俗话说:“人穷则反本”,当人们遇到困难和挫折的时候,就想回到老路上去,这是人之常情。只是,你不得不面对的一个现实就是,即便回头去继续做技术,也不再是原来那个听指挥听安排就好、做好执行就 OK 的一线工程师,工作“升维”已不可避免。一方面,每个人的内心都有成长的诉求;另外一方面,公司和团队也需要你承担更复杂、更具挑战性的任务。
|
||||
|
||||
所以,无论是做技术管理,还是做技术架构师,开启一条技术升维之路,都在所难免。即便不做技术管理者,要做好一位技术带头人或架构师,工作视角也要做如下的升级:
|
||||
|
||||
首先,从目标出发去看待技术。只有目标明确,才能选择最佳的技术方案,做出最好的技术决策。
|
||||
|
||||
其次,从评估的角度去看待技术。做工程师的时候,把一个技术方案设计好、实现出来就好了,而做了架构师之后,你需要非常清楚一个技术方案是通过哪些维度来评估其好坏优劣的。并且,当一个技术问题暴露出来之后,得迅速判断会造成什么影响,损失的边界在哪里,有多紧急,以决定要不要放下手头的项目去立一个紧急项目。
|
||||
|
||||
最后,从借助自己的技术到借助大家的技术。做技术的时候,了解自己能做什么就好了。但是无论是做管理者还是架构师,你都需要带人做事了,这个时候你就需要熟悉团队里每个人的技术情况,知道谁能胜任做什么事情,适合做什么事,然后借助大家的技术去做事。
|
||||
|
||||
综上你可以看到,即使是放弃管理继续做技术,从工程师进阶到架构师,也一样有很多的视角需要转换,有很多的能力需要锻炼。
|
||||
|
||||
所以,第三个药方就是:既然你避无可避,不如奋力向前。你要做的并不是要免除“后顾之忧”,而是需要意识到,你已经没有机会“后顾”了。
|
||||
|
||||
总之,技术转管理的纠结,归根结底是“对管理的患得和对技术的患失”。既然你已经看到,做管理不会让你“患得”,也不会让你“患失”,那么你是不是可以安心了呢?
|
||||
|
||||
向前冲吧,皮卡丘!
|
||||
|
||||
也欢迎给我留言,我们一起分享和探讨。
|
||||
|
||||
|
||||
|
||||
|
91
专栏/技术管理实战36讲/05作为技术管理者,我如何保持技术判断力?.md
Normal file
91
专栏/技术管理实战36讲/05作为技术管理者,我如何保持技术判断力?.md
Normal file
@ -0,0 +1,91 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
05 作为技术管理者,我如何保持技术判断力?
|
||||
转型做管理后,你可以用在技术上的时间会越来越少,尤其是写代码的机会越来越少,手越来越生,但是要做的技术评审和技术决策却有增无减,对技术判断力的要求反而也越来越高。这是因为你的决策产生的影响比之前更大了。
|
||||
|
||||
无怪乎会有新经理抱怨说:“技术管理者是有违人性的,一方面自己的技术越来越差,另外一方面却还要带领整个技术团队。”技术管理者对于如何保持技术能力的焦虑,由此可见一斑。
|
||||
|
||||
事实上,我们的上级和前辈也时常告诫我们,“技术管理者要保持自己的技术判断力”,可见这个问题是大家都看在眼里的,但是却很少有人告诉我们,技术判断力都包含了哪些内容,也很少告诉我们该怎么样去做。
|
||||
|
||||
今天,我就来聊聊,在管理工作越来越繁重的情况下,技术管理者该如何保持自己在技术上的判断力。
|
||||
|
||||
技术管理者,和普通管理者最大的区别,就是“技术”二字,这也是技术管理者最鲜明的标签和最大的竞争力,它是如此重要,但又令人不知所措,困扰着众多的技术新经理。
|
||||
|
||||
从技术工程师到技术管理者的转型,有很多做事的思路和方法都需要转变。其中一个重要的转变就是你和技术的关系,也就是技术对你来说,意味着什么。
|
||||
|
||||
当你还是一位工程师时,你是技术的操作者和实现者,所有的技术服务都从你的手中诞生;而在成为一个越来越成熟的管理者的过程中,你越来越少地直接去实操,慢慢变成了技术的应用者,你需要的是把这些技术服务装配成更大的服务和产品。
|
||||
|
||||
这么说可能有点枯燥,打一个比方来说,当你是一名技术工程师时,你需要关心的是一个电子芯片该如何实现;而如果你成为一名技术管理者后,你关心的则是如何使用这些电子芯片,组装成一部手机或其他设备。做管理前后对于技术的态度,就如同对芯片的态度一样。
|
||||
|
||||
由此可见,当工作角色对你的要求,从一个技术实现者变为一个技术应用者时,你和技术的关系就发生了变化,“技术能力”这个词的含义也悄悄发生了转变。如果你没有意识到这一点,困惑和焦虑几乎是必然发生的。
|
||||
|
||||
那么,从技术实现者到技术应用者,具体发生了哪些转变呢?
|
||||
|
||||
对于技术实现者来说,程序设计能力、编码实现能力、技术攻坚能力和技术评估能力,都是需要具备的,主要关心的是“怎么做”,属于“how”的范畴。
|
||||
|
||||
而对于技术应用者来说,技术评估能力变得尤其重要,因为技术管理者主要关心的是“要不要做”“做什么”,属于“why” 和 “what” 的范畴,是要在综合评估之后,做出决策和判断的。所以,很多前辈都会告诉我们要保持“技术判断力”,而并没有要求我们保持编码能力,原因就在这里。
|
||||
|
||||
那么该如何保持技术判断力呢?因为所有判断,都先要评估,所以技术判断力,其实就是指对技术的评估能力。你可能会说,技术评估能力还是虚的,具体都评估什么呢?
|
||||
|
||||
作为一个技术管理者,即技术应用者,要评估的维度主要是以下三个方面:
|
||||
|
||||
第一个维度是结果评估。即,你要回答“要不要做”,希望拿到什么结果,你要从哪几个维度去衡量结果,从哪几个技术指标去验收成果。
|
||||
|
||||
比如,你可能因为提升服务稳定性,去完善服务架构;也可能因为要提升数据准确性,去改写数据采集程序;还可能为了提升性能指标,去重构数据读写模块,等等。无论如何,你心里都需要很清楚,用什么技术指标来衡量团队的某项技术工作,而不只是完成一个个项目。
|
||||
|
||||
事关每项工作的效果和业绩,对结果的评估能力最为关键。虽然结果验收都是放在项目完成后,但是在事先就要明确如何验收,这样才能让大家有的放矢,以终为始。
|
||||
|
||||
第二个维度是可行性评估。可行性有两层含义:一是“能不能做”,二是“值不值得”。 能不能和值不值得,是两码事。不懂技术的管理者一般问的都是“能不能做”,而有经验的技术管理者和资深工程师,考虑的是“值不值得”。
|
||||
|
||||
所谓“值不值得”,就是成本收益问题。收益,往往是显而易见的;而成本,就有很多方面需要考虑了,这正是体现技术判断力的地方。
|
||||
|
||||
首先是“人财物时”等资源投入成本,这是几乎每位工程师和管理者都能考虑到的,即需要投入多少人、多少时间,甚至是多少资金和物资在该项目上,这项成本相对容易评估。
|
||||
|
||||
其次是维护成本,这是评估技术方案时要重点考虑的。由于我们考虑投入的时候,往往只考虑到项目发布,而发布后的维护成本很容易被忽略。
|
||||
|
||||
常见的技术维护成本有如下四个方面,依次是:
|
||||
|
||||
技术选型成本。这是指你在做技术选型的时候,选择不成熟的技术所带来的成本。越成熟的技术,其技术实现成本和人力成本都是相对要低的,但是并不是说,选择新技术就一定不划算,只要考虑到成本和风险,才能做出合理决策。
|
||||
|
||||
技术升级成本。这是指在评估技术方案的时候,其兼容性和扩展性水平带来的后期升级的难度和成本。
|
||||
|
||||
问题排查成本。在做技术实现的时候,要特别关注后续的问题排查。好的技术实现,分分钟可以排查出问题原因;而不好的技术实现和方案,查一个问题可能需要花上几天时间,成本差异不可同日而语。
|
||||
|
||||
代码维护成本。在编写代码的时候,要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白,修改起来是否简单、安全。
|
||||
|
||||
考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。
|
||||
|
||||
再次是机会成本,这是技术管理者做决策时要意识到的。即,当你把人力、时间花在这件事上,同时就等于放弃了另外一件事,而没有做另外这件事将带来什么样的影响呢?就是你要考虑的机会成本,你可能会因为这个思考而调整技术方案的选择。
|
||||
|
||||
最后,希望你还能意识到协作成本,即多人协作所增加的时间精力开销。一个方案的协作方越多,需要沟通协调的成本也就越高,可控度越低。如果可能的话,尽量减少不同团队和人员之间的耦合,这样会大大降低协作成本。
|
||||
|
||||
第三个评估维度,即风险评估。技术风险评估,也叫技术风险判断力。即,有哪些技术风险需要未雨绸缪,考虑该技术方案带来最大损失的可能性和边界,以及在什么情形下会发生。这项评估工作很考验技术管理者的技术经验和风险意识,而且需要借助全团队的技术力量来做出准确判断。
|
||||
|
||||
对于一个技术方案或一项技术决策,如果你能从以上三个维度去评估,就说明你拥有了很好的技术意识和判断力;另外,你还会发现,如果能做好技术评估工作,你的技术能力并不会降低,还会持续提高。
|
||||
|
||||
那么,如何提升自己的技术判断力呢?
|
||||
|
||||
判断力不是天生的,也不是一蹴而就的。新经理的技术判断力,基本都来自于之前技术上的实际操作,来自于自己的经验积累。而做管理之后,技术评估方面的要求更高了,研究技术的时间和精力却减少了,这该怎么破?
|
||||
|
||||
别忘了,自从你带团队的那一天起,你就已经不是一个人在战斗。所以,你可以依靠团队和更广的人脉,去拓展技术视野和技术判断力。常见的几个方式如下:
|
||||
|
||||
建立技术学习机制。盘点你负责的业务,需要哪些方面的技术,成立一个或几个核心的技术小组,让团队对各个方向的技术保持敏感,要求小组定期做交流和分享,这样你就可以保持技术的敏感度。
|
||||
|
||||
专项技术调研项目化。如果某项技术对团队的业务有重要的价值,可以专门立项做技术调研,并要求项目负责人做调研汇报。
|
||||
|
||||
和技术大牛交流。越是厉害的技术人,越能深入浅出地把技术讲明白,所以针对某项技术找大牛取经,也是学习的好途径。你看,虽然实际操刀的时间少了,但是你和技术大牛的交流机会多了,一方面因为你有更大的影响力了,另一方面,你和大牛有了共同的诉求,就是把技术“变现”,让技术产生价值。
|
||||
|
||||
听取工作汇报。因为你带的是技术团队,大部分工作都和技术相关,在读员工的周报、季度汇报时,相互探讨,也是一种切磋和学习。
|
||||
|
||||
总之,你会发现,技术管理人的技术水准的提升和保持,主要看能从周围人的身上汲取到多少信息和知识,而不再只是靠自学。
|
||||
|
||||
归根结底,从技术实现者到技术应用者的转变,不断提升的是技术的使用能力,而技术实现能力由于投入的时间越来越少,会逐渐减弱。如果说带团队做项目就像组装一部手机,你会越来越清楚如何把各个组件集成起来,但是你不见得会清楚每一个电子元器件内部的技术实现。
|
||||
|
||||
既然你选择了做更大的事情,就不得不适当放弃一些细节,放弃一些技术实现能力,不断提升你的技术判断力,让团队行走在正确的方向上。你说是不是这么个道理呢?
|
||||
|
||||
|
||||
|
||||
|
101
专栏/技术管理实战36讲/06我这样的风格能做管理吗?.md
Normal file
101
专栏/技术管理实战36讲/06我这样的风格能做管理吗?.md
Normal file
@ -0,0 +1,101 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
06 我这样的风格能做管理吗?
|
||||
有不少管理候选人,会小心翼翼地问我:“我是个内向的人,不像 A 那么热情洋溢,让我慷慨激昂地给大家打鸡血会很有挑战;我也不像 B 那么强势和有威严,让大家都服我似乎并不容易。这样看起来,我是不是不适合做管理呢?”
|
||||
|
||||
在女经理群体中,有一个常见的困惑是:“我是个女生,不喜欢和大家抽烟喝酒扯闲篇,很难和大家打成一片,带团队对我来说太挑战了!”
|
||||
|
||||
还有些管理者很苦恼地说:“我也想成为像某某那样的管理者,可是长时间下来我做不到,怎么办呢?”
|
||||
|
||||
甚至有位做了五年管理、带几十人团队的经理,问我一个困惑他多年的问题:“管理者是不是不能太 nice?”因为在他看来,亲和力太强的领导,下属会不敬重,因为不够威严。
|
||||
|
||||
类似这样的疑问还有很多,它们的共同模式是:先设置一个所谓“好”的管理方式和行为风格,然后发现自己做不到,于是很苦恼。
|
||||
|
||||
下面,我就来谈一谈管理风格的问题。
|
||||
|
||||
模仿,是人们学习新技能非常重要和常用的方式。当你尝试做管理的时候,也可能在不断模仿那些你认为“最优秀”的管理者,并希望像他们一样“成功”。
|
||||
|
||||
榜样给了你前进的方向、动力和信心,这对你的成长是很积极的影响。但不经意间,榜样同时也左右了你的认知,所以需要提醒自己一个问题:别让榜样限制住你对优秀管理者的想象,以及别把领导力的风格和领导力的高低划上等号。
|
||||
|
||||
事实上,优秀的管理者风格各异,比如马云、马化腾和马斯克,都能把企业做那么大,而且名字里都有“马”字,但是你能感受到他们的风格是如此不同。可见,领导力风格的差异并不妨碍你成为一个优秀的管理者。那么到底什么是领导力风格呢?而你自己又最适合哪种风格呢?
|
||||
|
||||
关于领导力风格,或者叫管理风格,如果你去网上搜索,会看到很多不同的视角和说法。如果真要给这些不同的说法找到一个底层的逻辑,我认为所谓管理风格,本质就是你和团队的协作方式,也就是你和团队的“位置关系”,即你站在团队的什么位置。如果还是难以想象,你可以把带团队,看作是在驾驭一辆马车,你和这几匹马是如何协作,一起把车拉到目的地呢?
|
||||
|
||||
其位置关系大体可以有这样四类:
|
||||
|
||||
|
||||
|
||||
四类管理风格示意图
|
||||
|
||||
第一类是发号施令型。管理者和团队的关系是:管理者发号施令,全程指挥,但不会亲力亲为去操作,团队成员只要按管理者说的做好执行,不需要问为什么。就好像一位坐在马车上驾驶车辆的车夫,他不参与拉车,但是马匹的一举一动,都听命于他的指令。所以,我们常常把这种管理风格,叫做指令式管理、命令式管理,或者指导式管理。
|
||||
|
||||
这样的管理者带给团队的往往是很强的控制气场和压迫感,没有人情味,让人有距离感,最符合大众眼中的“领导”的形象。这类管理者往往重事不重人,眼睛盯着目标和结果,对人的发展和成长关注较少。所以,通常团队执行力很强,但是梯队很难培养起来。
|
||||
|
||||
第二类是以身作则型。和指令式管理者很少亲力亲为的做法相反,以身作则的管理者凡事冲在最前面,是站在马匹中间,和大家一起奋力拉车的人。这类管理者非常享受和团队打成一片,很像一位身先士卒的将军,战斗力很强,很受团队拥戴,所以往往团队凝聚力也很强。
|
||||
|
||||
他们非常在意团队成员的想法和感受,并愿意提供帮助和支持,分担他们的工作和困难,因此我们称之为支持式管理。对于这类管理者来说,重人不重事,不过他们并不会忽视做事,只是不太去指导员工做事,而是倾向于直接替员工做事。
|
||||
|
||||
这类管理者更像一个带头大哥,员工会特别有归属感,但是这类管理者往往带不了大规模团队。
|
||||
|
||||
第三类是激发辅导型。这类管理者不会亲力亲为去帮员工做事,但是会去辅导和启发员工怎么去完成工作,并且提供鼓励、支持和反馈。换句话说,他们不会去替马拉车,但是会陪着马一起赶路,同时辅导马匹怎么样能够把路走好,以及要往哪里走。
|
||||
|
||||
这有点像球场上的教练,他们不上场,但会把握比赛节奏和方向,不断给球员提供指导和反馈。所以我们把这类管理风格称为教练式管理。教练式管理者既关心员工在做事的过程中有没有得到锻炼和成长,也关心事情本身有没有很好地完成,整体的步调和节奏如何,以及最后结果的好坏,属于重事也重人。
|
||||
|
||||
在这类管理者团队做事,个人成长是最显著的,团队梯队也能快速完善起来。但是由于这类风格对于管理者精力消耗比较大,很难覆盖到全体成员,所以比较适用于核心梯队的培养。
|
||||
|
||||
第四类是无为而治型。无为而治,似乎是很多管理者向往的境界,很多高级管理者都认为好的管理者应该是“没有我的时候,团队完全能自行运转”,第四类风格就有点这个意思。
|
||||
|
||||
他们往往安排好任务就“撒手不管”了,把工作完全授权给了团队成员,只是在约定的时间去检查结果是否达成,所以这类风格我们称之为授权式管理。就任务执行过程来看,他们是不重人也不重事的。
|
||||
|
||||
这类管理者对团队成员做事表现得非常放心,甚至让大家感觉有点漠不关心;对任务执行过程不关心,关心的只是他最在乎的目标和结果。在这类管理者团队中做事,对于不成熟的团队,成员就会变成野蛮生长;而对于成熟的团队,成员就会有很好的发挥空间和舞台,反而会得心应手。
|
||||
|
||||
综合上面所描述的四类领导力风格,简单概况如下:
|
||||
|
||||
指令式管理:重事不重人,关注目标和结果,喜欢发号施令但不亲力亲为。
|
||||
|
||||
支持式管理:重人不重事,希望带头冲锋亲力亲为,特别在意团队成员的感受,并替他们分担工作。
|
||||
|
||||
教练式管理:重人也重事,关注全局和方向,并在做事上给予教练式辅导和启发。
|
||||
|
||||
授权式管理:不重人也不重事,关注目标和结果,不关心过程和人员发展。
|
||||
|
||||
为了加深理解,我再用一个案例来示意一下。
|
||||
|
||||
三国的故事,中国人都耳熟能详,其中有一段叫“刘备入川”:刘备在落凤坡损失军师庞统之后,就调集荆州的诸葛亮来支援西川,这时诸葛亮就需要把守卫荆州的重担交给刘备的二弟关羽。那他将会怎么样嘱托关羽呢?
|
||||
|
||||
我们来看看四类不同风格的诸葛亮,会如何对关羽说呢?
|
||||
|
||||
指令式的诸葛亮会说:“我把荆州托付给你,你对曹操要采取抵抗的策略,而对东吴一定要采取联合的策略,你一定要照我说的做,否则荆州肯定会丢。”
|
||||
|
||||
支持式的诸葛亮会说:“兄弟,我去支援主公,没法和你一起守荆州了,但是有什么问题你随时告诉我,我全力支持!”
|
||||
|
||||
教练式的诸葛亮会说:“云长,荆州这个重担就交给你了,如果曹操来打荆州,你打算怎么应对呢?如果曹操和孙权一起来打,你又会怎么应对呢?”听完关羽的方案,教练式的诸葛亮会给出自己的建议:“你这么做荆州比较危险,你可以参考我的策略:北拒曹操,东和孙权。”
|
||||
|
||||
而授权式的诸葛亮会说:“云长,荆州就交给你了,你要确保万无一失,我相信你一定能搞定!”
|
||||
|
||||
所以你看,不同的风格,对于同一个事情,做法差别是很大的。那么,你会是哪种管理风格呢?你的上级和你认识的管理者,他们又偏重于哪个风格呢?我相信你心里已经有数了。
|
||||
|
||||
也许你会再问:“到底哪种风格最好呢?文章开头的几个问题还是没有答案啊。”
|
||||
|
||||
我想说,既然叫风格,就是手段层面的东西,评价手段我们往往是用有效无效来衡量,而不会用好坏来衡量,所以,这四类风格无所谓谁好谁坏。一个成熟的管理者应该对这四类风格都能有很好的了解和认知,甚至是能驾驭。
|
||||
|
||||
不过,不同的风格,在不同的场景下,的确会有不同的适用程度,我就简单列出几个场景做一些说明:
|
||||
|
||||
当一项工作不容有闪失,而你又是唯一熟悉、且最有掌控力的人时,一个命令式的你可能更能降低风险、达成目标。所以,命令式管理最适用于需要强执行的场景。
|
||||
|
||||
当一个团队特别需要凝聚力和斗志,需要攻坚的时候,一个支持式的你会促成很好的效果。所以,支持式管理特别能带团队士气和凝聚力,在带动大家热情和积极性方面很有优势。
|
||||
|
||||
当有一些核心人才需要重点培养,团队需要发展梯队的时候,一个教练式的你会带来明显的效果。他们不但能把事情做好,个人能力还能成长。虽然执行速度通常不会太快,但是不会偏离方向。
|
||||
|
||||
当团队梯队很成熟,团队成员需要发挥空间的时候,一个授权式的你能提供最恰当的管理方式。
|
||||
|
||||
当然,如果你能驾驭多种风格,那是非常厉害的。大部分管理者都还是以自己最拿手的风格来带团队,其他方式仅在必要时使用。
|
||||
|
||||
既然管理风格的本质就是你和团队的协作方式,是手段层面的东西,那么,不同的风格并不会妨碍你成为优秀的管理者,你自然也可以有自己的管理风格,不是吗?在专栏的后期,我还会继续探讨如何基于自己的风格,走出一条属于自己的管理之路,一起期待吧!
|
||||
|
||||
|
||||
|
||||
|
97
专栏/技术管理实战36讲/07我能做好管理吗,大家服我吗?.md
Normal file
97
专栏/技术管理实战36讲/07我能做好管理吗,大家服我吗?.md
Normal file
@ -0,0 +1,97 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
07 我能做好管理吗,大家服我吗?
|
||||
在新经理的常见困惑中,“不自信”是普遍存在的一个情况。尤其是当遇到一些挑战或挫折的时候,很容易产生“自我怀疑”,常见的说法有:
|
||||
|
||||
“这么点小事都没有处理好,我是不是不适合做管理啊?”
|
||||
|
||||
“大家对我的方案有异议,是不是不服我管?毕竟我不是团队里技术最强的。”
|
||||
|
||||
“我进公司晚,资历不如大家老,那应该怎么去管这些‘老人’呢?”
|
||||
|
||||
“上级对我的期待那么高,我能做好吗?”
|
||||
|
||||
归结起来,你会发现,新经理不自信的来源,主要是如下几点:
|
||||
|
||||
第一,管理经验不足和能力欠缺。对于很多管理事务不知道该怎么着手,在摸索前行中磕磕绊绊,于是怀疑自己没有能力做好管理。
|
||||
|
||||
第二,和团队成员对立比较。由于资历或能力不是团队里最突出的,担心团队里资历老或能力强的团队成员会不服自己,尤其是当这些人提出不同意见的时候,常常会引起新经理的挫败和颓丧。
|
||||
|
||||
第三,背负着沉重的包袱。因为担心管理工作做不好会辜负上级的期望,所以带着很大的压力去工作。
|
||||
|
||||
既然,我们清楚了引发管理自信不足的源头,那么该如何消除这些根源,提升管理自信呢?
|
||||
|
||||
我们先来探讨第一类自信困境:因欠缺管理经验和技能而引起的不自信。
|
||||
|
||||
这是每位管理者的必经阶段,其实也是学习所有新事物的必经阶段。你想想你刚接触技术工作的时候,是不是也经常会碰到一些不知所措的问题呢?
|
||||
|
||||
只不过不同的是,技术问题往往有比较标准的答案,通过查资料就能解决大部分问题;而管理问题则很少有标准答案,很多经验和技巧是在不断实践的过程中积累起来的,掌握起来不像技术问题那样可以查查资料就快速解决。这也正是管理有挑战的地方。
|
||||
|
||||
那么,有没有一些方法可以帮助你快速提升管理能力呢?
|
||||
|
||||
答案是有的,你可以从之前的工作经验中,迁移一些能力过来。你可能会说,之前的工作经验以技术为主,有什么能力可以迁移过来呢?为了回答好这个问题,我先介绍一个能力层次模型(见下图),叫“能力三核”,这个模型把能力分为三个层次:知识、技能和才干。
|
||||
|
||||
|
||||
|
||||
“能力三核”(来自盖洛普)
|
||||
|
||||
知识,是指你知道和理解的内容和信息,一般用深度和广度来衡量。由于大部分知识都是基于特定工作场景的,所以这部分能力迁移性不好。也就是说你很难把技术知识直接迁移到管理中来,所以关于管理的知识,是新经理要重点补习和加强的。
|
||||
|
||||
技能,是指你能操作和完成的技术,一般用熟练度来衡量。这个层次的能力就有一定的可迁移性了,这里我举几个例子来说明。
|
||||
|
||||
比如快速学习的能力,如果你在做技术时积累了快速学习的良好方法和技能,你可以稍加调整运用到学习管理中;
|
||||
|
||||
再比如进度控制能力,你在做工程师时,如果对完成一个项目有很好的进度控制能力,就可以把控制进度的方法和要点,运用在管理工作中。
|
||||
|
||||
其他容易迁移的能力还有很多,比如沟通表达的逻辑能力、规划工作目标的能力等,都是可以迁移到管理工作中的。所以,你可以专门思考一下,自己有哪些能力可以方便迁移的。
|
||||
|
||||
才干,是你长期生活工作所积淀和锤炼出来的模式、特质和品格。这个层次的“能力”是迁移性最强的,换句话说,你想不迁移过来都难。
|
||||
|
||||
比如自信,如果你是一个自信满满的人,那么这篇文章对你来说,就权当是开卷有益了;再比如前瞻,如果你是一个前瞻性很强的人,你可能会很习惯性地去规划团队未来的图景,并用未来的图景去激励团队。还有很多其他品质和模式,比如责任、热情、积极、果断、审慎、纪律、和谐、体谅、公正、完美等等,人人都有自己的模式,且每个人各不相同。
|
||||
|
||||
那你都有哪些才干和品质呢?一个常用的方法就是:从你之前的“成就事件”中去提取,或者从同事朋友对你的赞美中去归纳。如果你对自我优势探索这个话题感兴趣的话,可以去了解一下“盖洛普优势识别器 2.0”和“VIA 品格优势”等相关理论,它们对于才干和品格都有很系统的介绍。当你有意识地把你的才干和优势运用到管理中时,就会发现很多事情变得轻而易举、得心应手了。
|
||||
|
||||
你可以按照上面提到的知识、技能、才干这三个层次去梳理一下自己的能力,虽然很多知识层面的能力很难对管理产生直接帮助,但可以把一些技能和才干迁移过来,帮助你做好管理工作。同时,建立能力的分层意识,也会让你更加迅速而有效地积累管理经验。
|
||||
|
||||
上面我们探讨了第一类自信困境,接下来我们来看看第二类,也就是如何面对团队里的老资格员工和高能力员工。
|
||||
|
||||
如果你团队有不少资历比你老的员工,或者有一些技术能力比你强的员工,那么我得首先恭喜你。因为这至少说明两个问题:第一,你真的是非常优秀,以至于你能被公司赏识来负责这样一个团队;第二,因为这些老资格和高能力员工的存在,你有机会做出更好的业绩。
|
||||
|
||||
你可能还是会疑惑:“他们不听我的,不服我,说什么都是白搭!”对此,我只想对你说:你现在是团队的负责人,需要把自己从和任何团队成员的比较和竞争中抽离,把目光投向远方,去看看你将带出一个什么样的团队,以及在这个过程中,你能为公司、团队和各位团队成员带来什么样的成绩和成长。
|
||||
|
||||
当你不把团队成员放在你的对立面的时候,你和他们就没有任何竞争关系,因为所有的比较和竞争都是在同一个层次上才会发生,就好像你可能会和你的同学、同事比财富,但是不会和马云去比较一样。
|
||||
|
||||
所以,你要做的,不是和团队成员竞争、比较,也不是比团队每个人都强,而是要考虑如何让大家把自己的才智都发挥出来,去达成一个共同的团队目标。总之,你要做的不是管束和控制大家,而是引导和支持大家。
|
||||
|
||||
当你用引导方向和支持帮助的视角去看待你和那些老资格、高能力的员工时,你会因为自己的初心而不再有猜疑和恐惧,因为只有当你真的能够为团队带来更好发展的时候,才能赢得员工发自内心的真正的信赖。
|
||||
|
||||
所以,你要做的,就是用大家的力量,去做出更好的成果,而不是单单因为你的职位让大家服气。一旦你做到了,你也就完成了从工程师到管理者的蜕变,成为真正的 leader,自信也就油然而生。
|
||||
|
||||
最后,我们来看看第三类自信困境:因为背负了上级太高的期待而担心做不好。
|
||||
|
||||
如果说前两类自信来源于自我能力和角色认知的提升,那么第三类自信的增强则来源于外部反馈,尤其是上级。事实上,自信心的建立的确需要外部的正向反馈,这些正向反馈可以极大地提升你的自我认可度。
|
||||
|
||||
那么,如何才能得到外部持续的正向反馈呢?
|
||||
|
||||
我建议先把反馈通道建立起来,尤其是和上级的沟通通道,可以和上级约好一个例行的沟通机制,定期汇报团队工作,并就已经完成的一些重要工作征求上级的看法和评价。这其中,改进建议固然是很宝贵的,但是你还需要寻求一些肯定性的反馈,比如你可以问:“在你看起来,我有哪一两点做得是不错的吗?”或者“你能感受到我明显有进步的地方吗?”“我希望了解你比较看重什么?”
|
||||
|
||||
类似的问题,你也可以和合作伙伴去聊聊,除了请他们提意见,不要忘了问问他们有没有觉得你哪点做得好。当你越来越清楚自己擅长的工作方式是什么的时候,你的自信会和这些正向反馈一起螺旋上升。
|
||||
|
||||
这样,引发新经理不自信的三个困境,我们就探讨完了,我把它们简要总结一下:
|
||||
|
||||
第一,你可以通过梳理自己可迁移的能力,提升能力自信;
|
||||
|
||||
第二,你可以通过把自己从团队成员的对立面抽离,提升角色自信;
|
||||
|
||||
第三,你可以通过收集外部积极正向的反馈,提升自我认同。
|
||||
|
||||
倘若,此时此刻你正面临一项挑战,来不及通过上面的三种方式来增强信心,我曾经的上级传授给我一句话,非常有效,相信对于此时的你也一定会有帮助,她对我说:“你也许不是那个最强的人,但是你得相信,你是此时此刻做这事儿最合适的人。”
|
||||
|
||||
是的,既然你被任命为这个团队的负责人,你就是此次时刻带领这个团队最合适的人。你说呢?
|
||||
|
||||
|
||||
|
||||
|
95
专栏/技术管理实战36讲/08管理到底都做哪些事儿?.md
Normal file
95
专栏/技术管理实战36讲/08管理到底都做哪些事儿?.md
Normal file
@ -0,0 +1,95 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
08 管理到底都做哪些事儿?
|
||||
前面第一模块的七篇文章,都是围绕着“why”的问题展开,探讨你是否要做管理,以及如何面对刚刚做管理时的茫然、疑虑与纠结。如果你已经理顺了内心的力量,希望在管理这条路上大干一场,那么接下来,你还会遇到一个关于“what”的问题:管理到底都要做哪些事呢?
|
||||
|
||||
在实际的工作中,新经理基本上都是看上级怎么做,就“照葫芦画瓢”跟着学,之前的上级做过什么就跟着做什么。如果碰到的问题都是之前接触过的,那还好,一般都还是能应付的。
|
||||
|
||||
但管理恰恰不是一个靠一成不变的“套路”能做好的事情,每一个情境都是具体而崭新的,当面对新问题手足无措的时候,你可能就会殷切地期盼有人告诉你:管理到底都包含了哪些工作?对于这样的问题到底应该从哪里着手呢?
|
||||
|
||||
我在带新经理的时候,也常常会被问到这样类似的问题,比如:
|
||||
|
||||
“有没有管理框架或管理地图呢?若有的话,我就清楚都需要做哪些事儿了。”
|
||||
|
||||
“工程师有技术图谱,那么管理有没有管理图谱呢?若有的话,我也就知道该提升哪些能力了。”
|
||||
|
||||
不瞒你说,我自己也对这个问题非常感兴趣。作为工程师出身的管理者,我对于管理理论的依据和逻辑的追问是有执念的。我查阅了很多管理书籍和网页,但是并没有找到哪里有所谓的“管理框架”或“管理图谱”,对此我一直耿耿于怀。尤其当遇到类似下面这些复杂的“大问题”时,我对于管理框架的执念就更深了。
|
||||
|
||||
比如,我时常会被问到,“如何打造高效执行的团队?”“如何群策群力打胜仗?”“如何做团队建设?”等等。
|
||||
|
||||
这类问题的一个共同点就是“大”,虽然大家都可以凭经验给出几点建议,但很难给出系统的回答,因为这些问题本身包含着很多子问题。例如,第一个问题“如何打造高效执行的团队”,至少包含这样三个子问题:
|
||||
|
||||
对于第二个问题也是如此,“如何群策群力打胜仗”,也至少需要回答三个子问题:
|
||||
|
||||
对于第三个问题,“如何做团队建设”,要想回答好,也得先弄清楚:
|
||||
|
||||
于是你发现了,一个大问题背后依然是多个难以捉摸的大问题,很难理出头绪。
|
||||
|
||||
而且随着时代背景的不同,这些问题的答案也差异很大。比如工业时代的团队和知识经济时代的团队,对于如何提升团队工作效率,所采取的有效手段甚至是相反的:工业时代主要靠加强外驱,讲究“胡萝卜加大棒”,追求严格管控;而知识经济时代,更多是靠激发内驱,弹性工作制也好,发挥员工优势也好,都是希望员工更主动、自主,从而有更多的创造力。
|
||||
|
||||
这也就难怪,直到今天也没有人能够给“管理”下一个被普遍认同的定义,因为“管理”这个概念太复杂了,且随着时代背景、社会环境的改变而不断变化。
|
||||
|
||||
不过,这不妨碍我们先了解一下,管理学历史上的几位泰斗人物是怎么理解“管理”的。
|
||||
|
||||
古典管理理论的代表人物亨利·法约尔认为,“管理是由五项要素组成的一种普遍的人类活动,这五个要素是:计划、组织、指挥、协调和控制。”由此可以看出他特别关注管理的过程性,强调“做事”,不愧为“管理过程学派”的创始人。
|
||||
|
||||
“科学管理之父”弗雷德里克·泰勒认为,“管理就是确切地知道你要别人干什么,并使他用最好的方法去干。”他关注的焦点在于干什么,以及怎么干,有明显的目标性和方法性,强调“目标”和“做事”。
|
||||
|
||||
“现代管理学之父”彼得·德鲁克认为,“管理是一种实践,其本质不在于‘知’,而在于‘行’;其验证不在于逻辑,而在于成果。其唯一权威就是成就。”他这个说法的焦点在于实践性和结果性。众所周知,德鲁克是“目标管理理论”的创始人,尤其强调“目标”。
|
||||
|
||||
当代管理大师斯蒂芬·罗宾斯给管理的定义是:“所谓管理,是指同别人一起,或通过别人使活动完成得更有效的过程。”这个说法的背后蕴含着管理的三个要素:人、过程和有效,用正式一点的词汇叫组织性、过程性和目标性,强调了“带人”“做事”和“目标”。
|
||||
|
||||
显然,这些大师给了我们一些可以参考的真知灼见,但是该怎么实操呢?该如何带人,如何做事,如何规划方向呢?关于这类“大问题”,是不是就无迹可寻了呢?有没有办法一两句话能说清楚呢?
|
||||
|
||||
老子说,“治大国,若烹小鲜”,意思是说,很复杂的事物往往可以用很简单的事情来阐释。于是,一个常见的说法是把做管理比喻成“带兵打仗”;另外,也有人把做管理比喻成教练“指导球队比赛”,还有人认为做管理就像指挥家“指挥乐队演奏”,等等。
|
||||
|
||||
这些说法听起来都比管理本身要生动易懂。而且,你会发现它们有一个共同点,就是都由两个要素组成:一个要素关于人和组织的,像“带兵”“球队”“乐队”,简称“带人”;另一个要素是关于事务的,像“打仗”“指导比赛”“指挥演奏”等,简称“做事”。
|
||||
|
||||
如果让我对管理做一个形象而又生动的比喻的话,我更愿意把做管理看作是:一位马车夫驾驭着一辆多匹马拉的马车赶往目的地。这个比喻也体现了前面的两大要素:带人和做事,只不过这里的“人”是一群拉车的马,而“事”就是驾驶马车。
|
||||
|
||||
下面,我们就仔细探讨一下,如何驾驭好这辆马车和如何做管理有哪些相通之处。
|
||||
|
||||
|
||||
|
||||
“马车模型”示意图
|
||||
|
||||
首先,要想驾驭马车,就得先跳上马车;无论你之前是什么角色,跳上马车后,你就成为一名马车夫了。这就是所谓的“角色认知”。对应到管理就是,从一位工程师到一个团队的管理者,也需要对“管理者”这个角色有充分的认知。
|
||||
|
||||
其次,在驾驶马车之前,一定要先看看目的地在哪里,该走哪条路,朝哪个方向行进。对应到管理中,就是得弄清楚团队的工作目标,以及战略选择。我们往往称之为“目标管理”,或者“管理规划”,它代表着工作的方向性问题。
|
||||
|
||||
再次,我们开始驾驶马车,至少需要做两件事:一边抓住马缰,关照好马的状态和组织分工;一边挥舞马鞭,协调好整个马队的前进方向和节奏,让马匹一起用力把车拉到一个个里程碑和目的地,完成一段一段的旅程。前者对应到管理中,很像是在做人和组织相关的工作,我们称为“带人”,或者“团队建设”;后者对应到管理中,很像是在完成一个个项目或一项项任务,我们称为“做事”,或者叫“任务管理”。
|
||||
|
||||
最后,由于驾驶马车过程中,车夫需要和马匹,以及马车之外的其他环境要素进行互动和沟通,这对应到管理工作中,就是“管理沟通”。
|
||||
|
||||
综合上面驾驭马车的五个要素,对应到管理工作中,便是角色认知、管理规划、团队建设、任务管理和管理沟通五个管理要素。
|
||||
|
||||
其中,角色认知存在于管理工作的一言一行、一举一动,它无处不在,就好像空气一样,这是做好管理的基础和前提;而管理沟通贯穿于所有管理工作之中,把所有相关的合作方都连接在一起,就好像水流一样,是做好各项工作的手段和载体。管理规划、团队建设和任务管理,就是管理者的工作内容了,分别对应着看方向、带人和做事,这和近代几位管理大师的观点也是统一的。
|
||||
|
||||
我们把无所不在的空气般的认知作为“天”,把承载一切管理工作的沟通作为“地”,把管理者需要做的看方向、带人、做事放在中间,就组成了管理者的管理框架,由于看上去像一块三明治,我把它形象地称为“管理三明治”。
|
||||
|
||||
|
||||
|
||||
“管理三明治”框架示意图
|
||||
|
||||
你可能会说,这个框架还是很“虚”啊,看完之后依然不知道要从哪里着手去回答文章开头的那些大问题呢。
|
||||
|
||||
别着急,我会把“管理三明治”这个框图,细化为一个可以定位大部分管理问题的“管理全景图”,或者叫“管理图谱”,通过 13 个要素呈现给你,这样你就可以按图索骥地去拆解类似“如何打造高效执行的团队”“如何群策群力打胜仗”“如何顺利空降到一个新团队”这样的大问题了。
|
||||
|
||||
|
||||
|
||||
“管理图谱”
|
||||
|
||||
只是鉴于本文篇幅所限,我现在先不展开探讨,但是在后面的文章中,这 13 个要素一个都不会遗漏,我会逐一做具体阐释。
|
||||
|
||||
至此我们倒是可以回答文章标题的问题了。
|
||||
|
||||
如果你要问我,管理都做哪些事呢?我会说:“主要做好三件事:带人、做事、看方向,当然,做好这些事都要基于良好的角色认知和管理沟通。”
|
||||
|
||||
如果你要追问我,具体该如何带人、做事、看方向,以及该如何提升角色认知和管理沟通技巧呢?套用一句林徽因的台词,“答案很长,我准备用整个专栏来回答,你准备好要听了吗?”
|
||||
|
||||
|
||||
|
||||
|
81
专栏/技术管理实战36讲/09从工程师到管理者,角色都发生了哪些变化?.md
Normal file
81
专栏/技术管理实战36讲/09从工程师到管理者,角色都发生了哪些变化?.md
Normal file
@ -0,0 +1,81 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
09 从工程师到管理者,角色都发生了哪些变化?
|
||||
我们常常会用“很职业”去形容一个人某项工作做得很棒,意思是说,他很出色地做到了职位所期待和所要求的标准。那么,一个职业的管理者应该是什么样的呢?显然,他也要符合管理者这个角色的期待和要求,具体是什么呢?今天我们就来聊聊管理者角色认知的问题。
|
||||
|
||||
我曾经系统地访谈过一家著名互联网公司的几十位新经理和他们的上级经理,发现了一个很有意思的现象:新经理们希望我能够提供给他们一些工具和方法,让他们应对好日常的管理事务;而他们的上级经理,则无一例外地认为新经理最需要提升的是管理认知,其中最核心的就是管理者角色的认知和理解。
|
||||
|
||||
难道是他们之间存在分歧吗?我发现并不是,他们所期待的其实是同一个需求,只不过是同一个需求的不同层次,新经理的需求在能力层,即我们常说的“术”的层次;而他们上级的需求则在认知层,即我们常说的 “道”的层次。
|
||||
|
||||
显然,上级是希望新经理通过认知的改变,从而达到他们能力和行为上的改善。这恰恰呼应了罗伯特·迪尔茨的“NLP 逻辑层次图”,一个人的行为、能力、价值观,都源于一个最根本的认知,就是自我角色的设定。
|
||||
|
||||
|
||||
|
||||
NLP 逻辑层次图
|
||||
|
||||
今天我们就来详细地探讨一下,从一名职业的工程师,到一名职业的管理者,在角色上都有哪些东西发生了转变。
|
||||
|
||||
为了让这个角色的转换过程更加生动易懂,我再次拿出之前提到的“马车模型”。当你是一名出色工程师时,就好像马队里的“头马”,显然你是团队里最给力的人,也是你的上级最倚重的人;而当你成为这个团队的管理者,你就实现了一次蜕变,从“头马”转变为“车夫”,这个角色的转变对你来说意味着什么呢?
|
||||
|
||||
|
||||
|
||||
角色转换示意图
|
||||
|
||||
下面,我从以下十个角度,来说说我的看法。
|
||||
|
||||
第一个角度,从工作职责来看。作为“头马”时,你的核心职责是“拉好车”,其他事情都是次要的;而成为“车夫”后,虽然你依然可以去帮你的马队拉车,但你的核心职责却是“赶好车”,即如何确保这辆马车良好地行驶在正确的方向上,才是最需要你关心的。
|
||||
|
||||
对应到工作中就是,你做工程师时,完成好上级安排给你的工作就诸事大吉;而作为一个管理者,你要做的是带领整个团队往前走,上级只是帮你设定一个目标,剩下做什么、怎么做,都是你要考虑的,所有对达成目标有帮助的工作都是份内的。这就是“赶车”和“拉车”的不同。
|
||||
|
||||
第二个角度,从负责对象来看,即,你需要对谁负责。作为一名工程师,用他们自己的话说,“管好自己就可以了”,所以主要是对自己和自己的工作负责。而作为一名管理者,由于团队是上级和公司给你的资源,你需要对上级负责;你还得关心团队成员的发展和成长,对下级负责。
|
||||
|
||||
所以一个同学曾经幽默地比喻:做工程师是“一个人吃饱全家不饿”,做管理就是“上有老下有小”。我觉得非常贴切,更高的职位的确意味着更多的责任。
|
||||
|
||||
第三个角度,从关注焦点来看,也就是什么对你来说是最关注的。工程师一般是过程导向的,因为他们需要一步一步把工作执行到位,眼睛盯着的常常是“脚下的路”;而管理者是目标和结果导向的,他们时时关心目标和前进方向,盯着“远方的目标”,因为他们得决定要带着团队去哪里。
|
||||
|
||||
第四个角度,从工作内容和能力要求来看。工程师属于个人贡献者,也就是 HR 口中说的 IC(Individual Contributor),是靠个人专业能力来产生业绩的,工作内容以发挥专业能力为主,相对比较单一;而管理者要做成一项工作,除了技术判断力,还需要目标管理能力、团队规划能力、项目管理能力、沟通协调能力、团队建设能力等等,需要看方向的、带人的、做事的更加多维和立体的能力。
|
||||
|
||||
第五个角度,从任务来源来看。工程师的工作任务来源,主要是上级安排,听上级指挥;而管理者的工作内容,虽然也有上级工作的拆解和安排,但更多是靠自己筹划,然后和上级去沟通确认,从被动“等活儿”变为主动规划。
|
||||
|
||||
第六个角度,从实施手段来看。大部分工程师的工作还是要亲力亲为的,因为工程师角色是个人贡献者角色,所以主要靠自己完成。而管理者的工作清单涵盖了整体团队的工作,靠自己一个人是无论如何都做不完的,因此主要是依靠团队来完成。
|
||||
|
||||
第七个角度,从合作维度来看。工程师主要的合作内容就是和平级的伙伴共同做好执行,因此主要以平级合作为主。而作为管理者,合作的内容非常丰富,比如,需要和上级合作规划好整个团队的目标,和下级合作做好落地执行,和平级管理者合作完成联合项目,有时候还需要和平级的上、下级去一起协调资源和进度。所以合作的维度变得非常立体。
|
||||
|
||||
第八个角度,从和团队成员的合作关系来看。之前做工程师的时候,和大家都是平等竞合关系,以合作为主,也有“竞”的成分。
|
||||
|
||||
我们通常爱把“竞”和“争”连在一起说,但“竞”和“争”还是不同的。“争”意味着大家拼抢同一个东西,我得到的多就意味着你得到的少,此消彼长,比如摔跤、乒乓球、下棋等都是典型的“争”。而“竞”是朝向同一方向做比较的,比如百米赛跑、跳高、跳远等田径类比赛是典型的“竞”。
|
||||
|
||||
在之前平级的时候,你和其他同事虽然不会有“争”,但是有“竞”的成分在。而当你成为大家的上级,作为管理者来带领这个团队的时候,你和大家反而形成了全面合作的关系,“竞”的因素不存在了。因为“竞”和“争”都是发生在同一层次上的,要在同一个场地和同一个起跑线上,才有所谓的“竞争”;而随着你的晋升,你和之前的同事已经不在同一个层面上工作了,也就不存在“竞”的关系了,而是彼此间荣辱与共、休戚与共、成败与共的全面合作关系。
|
||||
|
||||
这一点新经理一定要认识到。我之所以特别强调这个观点,是因为很多新经理成为之前同事的上级之后,和大家相处有心理障碍,不太好意思指挥和安排他们的工作,用他们的话说,“毕竟之前都是平级”。我想告诉你的是,你们的关系其实比以前更好相处了,前提是你得认识到这一点。
|
||||
|
||||
第九个角度,从思维方式来看。做工程师的时候,大部分工作内容和工作要求都是执行,所以是明显的“执行思维”,特点是关注过程和细节,更重要的是关注风险和成本,希望通过对风险的排除和成本的掌控,来保证工作交付的确定性。
|
||||
|
||||
所以技术出身的人往往在项目执行,尤其是过程控制管理方面,有明显优势,他们天然就认为这不是什么难事。当然,他们估算排期一般也会比较保守,因为他们需要确保能完成才愿意答应。
|
||||
|
||||
而作为管理者,虽然也考虑风险和成本,但是更习惯于去关注做一件事能带来的可能性收益,并以此来判断是否值得投入资源去做,我们把这种叫“规划思维”。
|
||||
|
||||
由于管理者总是在盘算和筹划一些可能会对公司和团队有价值的事情,而没有仔细考虑风险和成本,所以在工程师的眼中,管理者时不时会提出一些“不靠谱”的期望和需求,但这正是两个角色关注的东西不同造成的。而这恰恰是一种很好的合作与互补:赶车的看方向选路径,而拉车的排除各种风险和困难,把车拉向前方。
|
||||
|
||||
第十个角度,从技术视角来看,即两个角色该如何看待技术。这个角度我们在前面的文章中已经探讨过,因为很多新经理都担心做了管理会丢掉技术,而其实只是看待技术的视角发生了变化。
|
||||
|
||||
做工程师的时候,技术是用来做事情的,掌握好技术的目的就是为了做好实施,看待技术是从如何运用的角度出发。而对于管理者来说,技术是达成目标的手段之一,所以看待技术是从如何评估的角度出发,评估该项技术是否是最合理的手段,以及如何选择才合理,并据此做出决策,因此常常被称为技术判断力。我们的老领导经常会告诫我们,即使做了管理,技术判断力不能丢,就是指这种能力。
|
||||
|
||||
至此,我从十个角度阐述了从一名工程师到一名管理者,角色上所发生的各种变化(如下图),但这就是全部了吗?显然还不是,你可以根据自己的经验,以及在管理工作中的体会和思考,不断丰富你对管理者这个角色的认知和理解。
|
||||
|
||||
|
||||
|
||||
工程师到管理者的角色转换
|
||||
|
||||
事实上,角色认知的改变,并不是一蹴而就的,需要你不断自我觉察和有意识地纠偏。也正是它足够基础和稳定,才会成为价值观、能力和行为这些层次的源头。
|
||||
|
||||
很多新经理的上级经理和高管,在找我给新经理做培训时,都无一例外地明确提出,要“提升大家的管理认知”。为什么呢?因为他们非常清楚,很多事情没做好,很多行为不职业,根源是认知还没有转变过来。所以,很多管理者的不职业,就集中体现在认知水平上。这也就引出了下一篇文章我们将要探讨的管理误区的问题。
|
||||
|
||||
那么关于从工程师转管理的角色转变,你有什么样的认知和理解呢?欢迎你留言和我一起探讨。
|
||||
|
||||
|
||||
|
||||
|
159
专栏/技术管理实战36讲/10新经理常踩的坑儿有哪些?.md
Normal file
159
专栏/技术管理实战36讲/10新经理常踩的坑儿有哪些?.md
Normal file
@ -0,0 +1,159 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
10 新经理常踩的坑儿有哪些?
|
||||
上一篇文章中,我系统地介绍了从一位工程师到一位管理者所需要做的角色转换。你是否已经对“如何做一名职业的管理者”胸有成竹了呢?
|
||||
|
||||
事实上,管理更多的是一门实践科学,从“知道”到“做到”,还需要长期地刻意练习。在实际操练过程中,你会碰到各种各样的问题,这会是常态。但是,如果你能提前知道前面有哪些“坑”是最容易踩到的,你也许就可以提前规避,选择跨过去或绕过去。
|
||||
|
||||
今天,我就把过去 10 年我遇到、看到、听到、搜集到的新经理最常见的管理误区,汇总为六个大类和你分享,希望可以帮你未雨绸缪。
|
||||
|
||||
第一类误区
|
||||
|
||||
常见的做法和说法如下:
|
||||
|
||||
不主动找活儿干,总是等待上级派活儿,如果上级没有明确安排,就“放羊”。
|
||||
|
||||
即使上级有了安排,还总是指望上级替他做决定该怎么做,选哪个方案。
|
||||
|
||||
在和上、下级沟通中,他主要充当“传话筒”的角色,常用句式是“老板说……”“某员工说……”,并没有反思每次沟通要达到的目的和效果是什么。
|
||||
|
||||
过于关注苦劳和付出,常见说法是“某某还是不错的,没有功劳也有苦劳。”
|
||||
|
||||
类似的行为和说法还有很多。你能够看出以上四个问题的共同点在哪里吗?你觉得这些问题背后的原因是什么?会带来哪些可能的后果呢?
|
||||
|
||||
相信你已经发现了,若用我们前面掌握的“马车模型”来看,这类问题的共同原因就在于:这位管理者还在“拉车”,而没有站在“马车夫”的位置上去驾驭整个马车;没有对整个团队的 ownership,工作比较被动,关注执行过程。
|
||||
|
||||
所以,我把这类问题归纳为:过程导向、被动执行。那么这种情况会带来哪些后果呢?
|
||||
|
||||
由于没有从“管理者”的视角出发,所以至少会带来如下三个后果:
|
||||
|
||||
团队方向感缺失。大家都只是着眼于手头工作,团队得不到愿景的凝聚和激励。
|
||||
|
||||
团队做不出有效的业绩。因为团队没有方向感,所以结果就很难有效。
|
||||
|
||||
无法带领一个团队。由于视角局限,所以还不具备带领团队的能力。
|
||||
|
||||
你身边是否有这样的管理者呢?你对此又是怎么看呢?
|
||||
|
||||
第二类误区
|
||||
|
||||
常见的相关说法有:
|
||||
|
||||
“某某做得太慢了,还是我来做吧,他半天的工作,我两个小时就搞定了。”
|
||||
|
||||
“团队离了我就不转了,里里外外都靠我操心,他们都担不起这个责任。”
|
||||
|
||||
“某某的工作主要靠我……”“在我的指导下,某某才……”“这件事主要是我做的……”
|
||||
|
||||
关于上述的这三个问题,我分别用三个词来概况:
|
||||
|
||||
问题 1,叫“包工作”。也就是说,他作为一个管理者,把团队成员力所能及的工作都做了。
|
||||
|
||||
问题 2,叫“包责任”。也就是说,他作为团队的负责人,把团队成员每个人应该自己承担的责任,都包在他一个人身上了。
|
||||
|
||||
问题 3,叫“包功劳”。为了体现自己的能干,处处凸显自己的功劳,把团队成员的业绩和工作成果也都放在自己头上了。
|
||||
|
||||
由于这类问题突出一个“包”字,所以我把它归纳为:大包大揽、唯我最强。
|
||||
|
||||
我相信,你身边一定有这样的管理者,甚至你还曾经遇到过,而且对于其中某些大包大揽的行为,你可能还挺钦佩他的能力和担当。那么,你是否意识到,大包大揽的管理者也可能会带来这样的后果:
|
||||
|
||||
梯队问题:大树底下寸草不生,梯队迟迟培养不起来。因为梯队的培养需要授权,需要让高潜人才有发挥空间并承担相应的责任。
|
||||
|
||||
激励问题:由于管理者冲得太靠前,团队成员积极性受挫,遇事往后缩。
|
||||
|
||||
个人发展问题:由于得不到团队成员的有效支持,自己又忙又累,做不了更大的业务。
|
||||
|
||||
正因为如此,有些成熟公司如京东就有规定,如果你没有培养出可以完全顶替你位置的人,你是不能晋升的。
|
||||
|
||||
第三类误区
|
||||
|
||||
常见的相关说法有:
|
||||
|
||||
“好好干,我不会亏待你的,我绝不会让跟着我的兄弟们吃亏!”
|
||||
|
||||
上面这三个问题,其实是两类管理者的表现,我合并在一起了。
|
||||
|
||||
第一类是“带头大哥”式的管理者,讲究的是兄弟感情,在他们心目中,不但兄弟的工作是我的, 兄弟人也是我的。这类管理者可能在某些情况下特别有战斗力,但是一旦情况有变,对公司的破坏性也是非常大的,因为他忘记了他带的团队是公司的资源,而不是自己的,所以不可能成为一个职业的管理者。
|
||||
|
||||
而后两类问题描述的是和第一类几乎相反的一类管理者,由于团队里有资深的高级工程师,他在技术判断力方面不如这些高工,索性就给这些高工做起了“保姆”,而忘记了自己才是这个团队的舵手和船长,因此也不是一个职业的管理者。
|
||||
|
||||
我把这两类不职业的情况放在一起,归纳为:带头大哥、当家保姆。这类问题带来的后果大体如下:
|
||||
|
||||
不职业的管理风格和文化,这会给公司带来很大的潜在风险。
|
||||
|
||||
那你是这样的管理风格吗?你团队里有资深高工吗?此时,职业与否,才能体现出你作为管理者的成熟度。
|
||||
|
||||
第四类误区
|
||||
|
||||
常见的相关说法有:
|
||||
|
||||
“让团队加班的话,得给大家发加班费,不然没法提升积极性。”
|
||||
|
||||
“像某某那样的人才适合做管理,我跟他太不一样了,所以不适合做管理。”
|
||||
|
||||
“还有个 Bug 没修复,不能发布,我们一直都是这么规定的。”
|
||||
|
||||
上面的这些说法是不是很常见呢?你作为工程师时应该一定不止一次地遇到过,甚至也曾经这样说过。作为一位工程师,有上面的这些言论似乎也无伤大雅,但是如果作为一个团队的管理者还这样说的话,就明显是掉到“坑”里了。
|
||||
|
||||
这个“坑”是什么呢?就是:单一视角、固化思维。往往因为某个要素不具备就否定所有的可能性,比如上面提到的“要想做事,就得招人”“要想提高积极性就得发加班费”“只有某某那样的人才能做管理”“某个 Bug 没有修复就不能发布”等等,思维模式非常单一。这样造成的后果是:
|
||||
|
||||
习惯性卡住。遇到问题和困难,很容易被卡住,到处都是绕不过去的鸿沟。
|
||||
|
||||
认知层次低。由于被单一惯性思维所支配,认知层次和考虑问题的维度无法提升。
|
||||
|
||||
难堪重任。由于创造性地解决问题的能力不足,难以承担具有挑战性的工作。
|
||||
|
||||
所以,如果你已经走上了管理岗位,请务必避开这个误区。
|
||||
|
||||
第五类误区
|
||||
|
||||
常见的相关说法有:
|
||||
|
||||
“这个是测试的问题,这个是产品的问题,这个是别的部门的问题。”
|
||||
|
||||
上面的这些说法也很眼熟吧?因为这在工程师团队里非常常见。相信明眼如你,一下子就看出来这类问题的共同特点就是:自扫门前雪、固守边界。
|
||||
|
||||
我们都知道,角色和责任的边界划分,是为了分工和合作,但由于很多大型项目有赖于多个团队一起协作完成,所以又需要有人主动站出来,去承担边界模糊的那部分职责。作为一个员工,边界分明无可厚非,但是作为一个管理者,就需要以全局的目标为己任,才能拿到公司要的业绩结果。
|
||||
|
||||
所以,这类问题明显的管理者,常常带来这样的后果:
|
||||
|
||||
个人影响力无法扩展。因为目光和手脚都局限在团队内,所以无法在更大的范围产生影响力,也就无法成为更高级的管理者。
|
||||
|
||||
正因如此,作为管理者,是要站高一层来看待问题的。
|
||||
|
||||
第六类误区
|
||||
|
||||
这个我已经在前面的文章中探讨和解决过了,常见的说法有:
|
||||
|
||||
“突然不写代码了,感觉吃饭的家伙没了,心里发虚。”
|
||||
|
||||
“管理工作太琐碎,感觉离技术越来越远,现在特别担心个人发展。”
|
||||
|
||||
“管理是个矛盾的事情,自己技术专业性越来越差,却要带领整个团队。”
|
||||
|
||||
这类问题的核心原因是把管理摆在了和技术对立的位置,同时由于管理能力还没有强大到可以作为自己的核心竞争力,因此忧虑自己的技术会落后,从而失去生存能力。
|
||||
|
||||
我把这类问题归纳为:“患得患失”。这造成的后果会有:
|
||||
|
||||
至此,六类管理误区我就分享完毕了,你是否能够在实际的管理工作中一眼认出它们呢?我们再来回顾一下这六类误区都是什么:
|
||||
|
||||
第一类:过程导向、被动执行;
|
||||
|
||||
第二类:大包大揽、唯我最强;
|
||||
|
||||
第三类:带头大哥、当家保姆;
|
||||
|
||||
第四类:单一视角、固化思维;
|
||||
|
||||
第五类:自扫门前雪、固守边界;
|
||||
|
||||
第六类:患得患失。
|
||||
|
||||
所有上面这些“坑”,都是前人用血泪教训换来的,希望你在前行的道路上,能够认清楚这些“坑”,或规避,或跨越,驾驭着你的“马车”一往无前。
|
||||
|
||||
|
||||
|
||||
|
115
专栏/技术管理实战36讲/11我刚开始带团队,从哪里着手呢?.md
Normal file
115
专栏/技术管理实战36讲/11我刚开始带团队,从哪里着手呢?.md
Normal file
@ -0,0 +1,115 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
11 我刚开始带团队,从哪里着手呢?
|
||||
一个快速发展的行业会推着你往前走,不会等你万事俱备了才让你带团队,泛互联网就是这样一个领域。
|
||||
|
||||
也许你还没想过要做管理,而且你的上级也并不希望你做纯粹的人力管理,但是“带团队”这个事情,却已经变得不可避免。换句话说,你叫什么不重要,头衔也不重要,重要的是,你很快就得带着一个小团队做事了。
|
||||
|
||||
很多人对于做技术,那是胸有成竹、毫不含糊,但是对于带团队这事儿,却常常不知道该从哪里下手。你是否也有这个困惑呢?类似的情形还有:
|
||||
|
||||
你需要接手一个新团队,而这个团队并不是你一点一点逐渐带起来的时候。
|
||||
|
||||
组织调整,把两个或多个团队的人塞给你,你正在考虑怎么整合这个团队的时候。
|
||||
|
||||
季度交替,或者年度交替之际,你需要给上级做一个阶段性的管理汇报,虽然有前人的汇报模板,但是“知其然不知其所以然”,不太能抓住核心的时候。
|
||||
|
||||
这样的一些时刻,你是否历历在目呢?还记得你是如何应对的吗?很多技术 leader 就这种情形给我出的题目常常是这样的:
|
||||
|
||||
“新团队人员各种问题,各种人心惶惶,非常棘手,该怎么应对呢?”
|
||||
|
||||
“新接手的服务各种问题,手忙脚乱,各种不靠谱……”
|
||||
|
||||
“成天开会,各种业务讨论,顾不上和员工熟悉……”
|
||||
|
||||
……
|
||||
|
||||
诸如此类疑惑比比皆是。
|
||||
|
||||
显然,这些问题是不可回避的,而且这些其实都在正常的管理工作范畴内。只是,这类困惑有一个共性的问题在于,管理者都一下子陷在问题里了,期待着解决掉这些问题之后,事情就都好了,这是典型的问题驱动型思维。
|
||||
|
||||
大家应该都知道大禹治水的故事:当洪水泛滥的时候,大禹之前的治理者都试图通过“堵漏”的方式来解决,效果并不好;直到大禹从之前的失败中汲取教训,采取“疏导”的方式来治理,引导洪水流向某一个方向,大水才由此得到了有效的控制。
|
||||
|
||||
这个道理大家都明白,只是我们在茫然和忙乱的时候,就一时全忘了。而作为一个 leader,“堵漏”的工作固然要做,但是有没有一个“全盘规划”的指引,清不清楚把团队带往何方,这才是不同 leader 领导水平的差距所在。
|
||||
|
||||
而我们今天要谈论的“管理规划”,就是要回答“把团队带往何方”的这个方向性问题。通过理清未来的发展来理顺当前问题的带团队思路,我称之为规划驱动型思维。
|
||||
|
||||
那么,关于团队方向的规划,具体该怎么操作呢?
|
||||
|
||||
你一定还记得我们前文中提到的“马车模型”,一个类似的问题是,一辆马车交给你,在驾驶它上路之前,你先做哪件事呢?
|
||||
|
||||
你可能会有很多的想法,但我觉得你至少需要思考四个问题。
|
||||
|
||||
第一个问题是,你需要先看一下,这是辆什么车。
|
||||
|
||||
你可能会问,“这是辆什么车有这样重要吗?”“管你是什么车,我都给你拉到目的地就行了呗!”而问题恰恰在于,如果你不清楚拉的是辆什么车,你就没法设定你的目的地,也不清楚该找什么马来拉,更不知道该走哪条路。
|
||||
|
||||
有这么严重吗?还真有。我举例来说明下:
|
||||
|
||||
如果你拉的是一辆长途旅行车。你的目的地就可以设定的非常清楚和鲜明,平安、快速、舒适地把客人送到指定目的地,就是你的职责和使命。你的车内是否舒适、马匹的选择是否快速、选择的路线是否安全等等都是你要考虑的。
|
||||
|
||||
而如果你拉的是一辆观光旅游车。你的目的地可以很清楚,也可以不清楚,因为你这辆车的使命在路上,核心是这个过程能否让观光客满意。此时,你的车体设计能否让乘客很方便观赏路上的景色、你的马匹选择是否速度适中、以及路线的选择是否风景优美,就变成了此时你要考虑的。
|
||||
|
||||
而如果你拉的是一辆送货的货车,那么你需要考虑的就是你的车是否满足货物要求的环境、一车次能拉多少货、以及马匹和路线的选择,以尽快到达交货地点。要考虑的问题和长途旅行、旅游观光,显然有着巨大的差异。
|
||||
|
||||
你还可以想到很多种马车,比如马拉雪橇、古代的战车等等。每辆车设计出来,都是为了满足特定需求的,你的团队亦是如此。
|
||||
|
||||
弄清楚它是一个背负着什么样职责和使命的团队,决定了你需要设定什么样的工作目标,并通过哪些要素来衡量你的目标;决定了你需要什么样的人加入你的团队,以及需要多少;还决定了你选择什么样手段,投入什么样的资源来完成工作。
|
||||
|
||||
这个问题是如此重要,以至于我把对于这个问题的回答,作为管理规划的第一个要素,称之为团队“职能”。这是管理工作的起点。关于如何设定团队的职能,我将在下一篇文章详细介绍。而此时我最关心的是,你是否可以毫不迟疑、非常简练地说出你团队的职责和使命呢?
|
||||
|
||||
第二个必须要思考的问题是,你得看看,你要把这辆车拉到哪里去。
|
||||
|
||||
只有明确了要去的目的地在哪里,才能评估需要什么样的马、多少匹,以及有哪些路线可以选择。这个关于“目的地在哪里”的问题,是管理规划的第二个要素,称为“目标”。
|
||||
|
||||
对于为什么要设定目标,很少会有人质疑,因为大家都认为设定目标是理所当然的事情。那么你有没有想过,为团队设定清晰的目标,可以带来哪些好处呢?
|
||||
|
||||
目标设定的最基本的初衷就是着眼自己想要的结果,去实现资源的有效配置。除此之外,目标还有非常好的几个附加效果:
|
||||
|
||||
首先,清晰明确的目标可以凝聚团队成员的力量,让大家劲往一处使,提升团队凝聚力;
|
||||
|
||||
其次,清晰的目标还是执行力的必要要素,你可以回想团队取得的每一个执行出色的项目,目标一定是非常清晰;
|
||||
|
||||
再次,清晰的目标还能提升判断力,如果你能够对某个突发状况快速决策,你一定非常清晰你当时想要的是什么;
|
||||
|
||||
最后,清晰的目标本身就是激励,当员工很清楚自己的工作目标,方向感很清晰的时候,他们更容易进入心流状态,即,一种投入度非常高,沉浸其中、物我两忘的工作状态。
|
||||
|
||||
所以,你是否更加重视目标设定了呢?实际上,没有目标的团队很少,但是想设定清晰明确的目标,对于技术团队来说又是非常困难的,因为工程师的工作大部分难以量化。那么,如何设定清晰明确的目标呢?我们在后面的文章还会专门全面来探讨的。
|
||||
|
||||
第三个必须要思考的问题是,你得盘点一下你有哪些马,它们情况如何。
|
||||
|
||||
做管理的主要工作内容是“带团队”,因为所有的工作,都是靠团队来落地完成的,他们是真正“拉车”的人。就好像马匹是马车的动力之源一样,团队就是你达成团队目标和使命的发动机。
|
||||
|
||||
所以,盘点自己的团队,以及看看在整个“赶路“的过程中要如何升级完善自己的团队,并思考在达成目标之后你期待收获一个什么样的团队,都是必须要考虑的问题。这就是管理规划的第三个要素,称之为“团队”,我们将会在后续的文章中专门探讨团队组织规划。
|
||||
|
||||
第四个必须要思考的问题是,你选择走哪条路。
|
||||
|
||||
也许你会说,前面有了职责,有了目标,有了团队,接下来不应该就是赶路了吗?我想说,在赶路之前,你还得先看看有哪些路可以走,即,你有哪些不同的选择,各自需要多少资源预算。
|
||||
|
||||
如果你选崎岖的近路,可能你需要非常贵重的马中的“特种兵”,并配给高精尖的装备;而如果你选择宽阔的大路,你可能需要跑得快、耐力强的马,路上带的补给也会因为路况而有所差异。因此,路径的不同选择,会带来资源投入的差异,从而,你向公司申请资源的类别和规模也是不同的。由于公司的预算是要提前做的,因此在马车出发前,即在规划的时候,就要算好。
|
||||
|
||||
这里我还需要说明一下,不要混淆路径选择和计划制定。这二者最大的区别在于,路径选择主要是为了预算资源,而制定计划主要是为了执行过程可控。
|
||||
|
||||
至此,我们已分别探讨了管理规划的四个要素,对应明确回答了下面这四个问题:
|
||||
|
||||
你的上级会很关心这四个问题(也可参考下图)。当你能系统地把这些问题清晰地呈现给上级时,说明你对团队已有了很好的掌控力,并且还会让上级觉得,这辆车,跑不偏!
|
||||
|
||||
|
||||
|
||||
“马车模型之规划四要素”
|
||||
|
||||
综上所述,所谓的管理规划,其实就是要管理者说明白一个问题,即,你想要什么目标,以及你需要投入什么资源。由于目标取决于团队的职能,而团队又是管理者的核心资源。所以,一份合格的规划报告,至少需要体现职能、目标、团队、路径这四个要素。
|
||||
|
||||
值得说明的是,这四个要素并不是彼此孤立和静止的,而是相互关联、动态平衡的(如下图)。其中最稳定的要素是职能,它是管理的起点。
|
||||
|
||||
|
||||
|
||||
“规划四要素”关系图
|
||||
|
||||
中国有句谚语叫“磨刀不误砍柴工”,磨刀虽然看上去花些时间,却能让后续的砍柴工作更加有效。作为管理者,花些时间来做做自己团队的管理规划,绝对是值得和必要的。那么,你大约多久会审视一下自己团队的规划呢?
|
||||
|
||||
|
||||
|
||||
|
105
专栏/技术管理实战36讲/12如何界定我团队是干什么的呢?.md
Normal file
105
专栏/技术管理实战36讲/12如何界定我团队是干什么的呢?.md
Normal file
@ -0,0 +1,105 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
12 如何界定我团队是干什么的呢?
|
||||
在上一篇文章中,我们把管理规划拆解为四个最核心的要素来着手操作,分别是:
|
||||
|
||||
职能,关于团队是干什么的;
|
||||
|
||||
目标,关于要带团队去哪里;
|
||||
|
||||
团队,关于依靠谁去达成目标;
|
||||
|
||||
路径,关于走哪条路以及投入哪些资源。
|
||||
|
||||
本文,我们就具体来看看第一个核心要素,如何明确界定一个团队的职能。
|
||||
|
||||
可能很多人并不认为这个问题有多难,觉得自己很清楚自己团队的职能。
|
||||
|
||||
但事实上,真正用心思考自己团队的职能,并用简洁凝练的几个词或一句话提炼出来的管理者只是少数。就在前些天,一个部门负责人询问他部门的几十位经理是负责什么的,其中能够简明扼要说出自己团队职责的比例,大约是 25%。你是在这 25% 之中吗?
|
||||
|
||||
要判断自己是否真的清楚团队职能,你可以试着问一下自己这三个问题:
|
||||
|
||||
公司为什么要给我这批资源(指这个团队)?是希望我产出什么?
|
||||
|
||||
怎么样,你能立即对这三个问题做出回应吗?如果能够毫不迟疑地作答,说明你很清楚自己团队的职能。如果你的表现确实如此,我想追问一句:“你可以用很简洁的语言来陈述它吗?”如果你的答案依然是肯定的,我想再追加的一个问题是:“你团队的成员,也都能准确无误地说出来吗?”
|
||||
|
||||
你可能会不舒服,为什么我要咄咄逼人地连续追问你呢?我只是想告诉你,只有连你的团队成员都非常清楚团队的职能定位时,才能收到如下的这些效果。
|
||||
|
||||
大家都知道自己是做什么的,同时,知道做什么对于团队来说非常重要。
|
||||
|
||||
大家都很容易去主动思考,要提升哪方面的能力,对团队来说是最有帮助的。
|
||||
|
||||
大家更容易理解自己工作的价值和意义,从而增强对团队的认同度和归属感。
|
||||
|
||||
所以你看,清晰的职能定位以及对职能的充分沟通,可以提升团队凝聚力、员工归属感和员工自驱力,在当今时代,这是多么重要的管理要素啊!
|
||||
|
||||
那么,究竟该如何明确团队的职能定位呢?
|
||||
|
||||
首先,我介绍一下团队职能的两个层次:基本的职责和升华的使命。
|
||||
|
||||
职责,是团队职能的下限,即,至少要完成的工作,如果这些职责都搞不定,意味着团队的基本价值都不能体现。我拿前端团队来举个例子,他们的基本职责就是要保证每个项目高质量开发和顺利发布,如果项目常常不能按时保质完成,就说明前端团队连基本的职责都不能胜任。
|
||||
|
||||
一般来说,团队的基本职责,是由上级给定的,上级在把这个团队交给你负责的时候,已经给你提了期待,只不过有的上级会明确交代,而有的上级默认你很清楚。所以,你无论如何都需要弄清楚团队的基本职责,否则肯定会失职。
|
||||
|
||||
使命,是团队职能的上限,即,如果我们团队做得好,就能承担更大的职责,体现出更大的价值。使命达成后的愿景,常常是令人期待和憧憬的。我还是拿前端团队来举例子,如果前端团队的 leader 认为,除了保证项目的高质量发布之外,还能做出一些通用组件、服务平台,甚至是行业标准,在整个前端领域都有更大的影响力,那么这就是这位 leader 为团队规划的使命和愿景。
|
||||
|
||||
如果说基本职责通常是上级给定的,那么使命愿景则常常是团队 leader 自己的规划和设想。上级一般不会作出这样的要求,最多就是提一下期待,团队做不到也不会认为是团队失职。但是,如果团队做到了,就会是非常亮眼的成绩,团队成员也会受到很大的激励和鼓舞,管理者的领导能力也必定不俗。
|
||||
|
||||
也许你会问,团队清楚自己的基本职责就够了吧?要使命干啥,给团队“画大饼”吗?
|
||||
|
||||
你可以说是“画大饼”,但是我想用另外两个词来形容会更贴切:基本职责解决的是“团队生存”问题,而使命解决的是“团队幸福”问题。对于有的人来说,看不到幸福的希望,则生存也将失去意义。
|
||||
|
||||
我带过一位测试经理,他带的测试团队工作非常认真负责,他个人和他团队在整个技术部有口皆碑,很受认可。就是这么靠谱的一位 leader,一天突然跟我说想看看别的发展机会,因为做了几年测试,工作太熟悉了,没有挑战,也没有成长。
|
||||
|
||||
于是我问他,“你觉得你团队的工作没有挑战,你能否告诉我你团队是做什么的吗?”
|
||||
|
||||
他说:“我负责的是测试团队,负责交付高质量的项目,目前大家做得不错,也比较熟练。”
|
||||
|
||||
我继续问他:“你的团队叫‘QA’团队,你知道‘QA’是什么意思吗?”
|
||||
|
||||
他回答说:“Quality Assurance,质量保证吧?”
|
||||
|
||||
我继续问:“既然你负责咱们公司所有产品的质量保证工作,那你觉得就是做好测试吗?”
|
||||
|
||||
他若有所悟。我继续对他说:“如果你认为自己团队就是做测试的,保证项目的高质量发布就是你的使命;而如果你把用户能感知到的所有产品质量问题,都纳入质量保障的工作范畴,那你团队还有太多的事情没有做,比如线上质量问题的搜集、整理、跟进、解决、反馈等,以及你是否搭建了产品质量的评估体系。显然都还没做。所以你看,一个仅仅做好测试工作的团队 leader,和一个能搭建公司完整质量保障体系的团队 leader,你觉得挑战和能力要求是一样的吗?”
|
||||
|
||||
听我这么一说,他顿时豁然开朗,欣然地筹划团队新的发展去了。其实他之前觉得没成长只是被自己潜意识的职责定位给限制住罢了。时隔一年多后,他还在带着原来的团队稳步地发展和成长,并没有贸然换工作。
|
||||
|
||||
那么,你是否也感受到了,团队职责的升华,可以为自己和团队带来何其广阔的发展空间?你是否还认为团队使命是可有可无的呢?
|
||||
|
||||
接下来,我们来探讨一下设定团队职责和使命的方法和步骤,大体分为三步:
|
||||
|
||||
第一步,收集信息。可从以下四个角度来梳理职能信息:
|
||||
|
||||
向上沟通。听听上级对你团队的期待和要求,以及希望用什么维度来衡量你做得好还是不好。这个信息非常重要,团队的初始定位和基本职责,一般都是上级直接给定的。
|
||||
|
||||
向下沟通。主要是和大家探讨对团队业务的看法和理解,以及对未来发展的期待,为以后的沟通做好铺垫。
|
||||
|
||||
左看右看。主要是看职能定位的边界在哪里,最好和兄弟团队的职能是无缝对接的。但不要覆盖兄弟团队的职责,否则会带来各种合作上的冲突。其实,快速发展的公司,要做的事情非常多,海阔天空,即便是广度不够,深度也还有作为空间,真没必要和兄弟团队争抢地盘。
|
||||
|
||||
你的理解。即,你对业务的理解,你对领域的理解,你对团队的期待,以及你对自己的期待。团队的更高职责,即,团队使命和愿景,往往来自于你的设想。
|
||||
|
||||
第二步,提炼和升华。
|
||||
|
||||
团队的职责和使命,不能只停留在 leader 的脑海中,为了方便记忆和传播,则必须从上述信息中进行提炼和升华。提炼和升华有三个要点:
|
||||
|
||||
职责的提炼。基于上级的期待和要求,以及你对业务核心价值的理解,最好用上级和团队成员、兄弟部门都易于理解的语言,对职责进行简短化提炼,并尽可能长时间稳定下来。
|
||||
|
||||
使命的升华。基于基本职责,寻找团队对于部门和公司的独特价值,并和行业发展趋势结合,设定自己的期待。要注意使用基于“结果”的描述,而非基于“过程”的描述。比如保证项目交付质量,是对结果的描述;而负责项目测试,则是对过程的描述。相比之下,基于结果的描述会更有使命感。
|
||||
|
||||
确定衡量维度。一般来说,团队的职责和使命决定了衡量的维度,但是如果有明确的关于衡量维度的说法,会让员工对职责和使命有更深刻的理解。常见的案例有:服务端团队,会特别重视性能、稳定性、扩展性等维度;而前端团队,往往重视开发效率、兼容性、安全性等维度;数据团队关注数据准确性、完整性、及时性、安全性等维度。你也需要根据自己团队的职能,向员工明确传递,什么指标维度对团队是最重要的。
|
||||
|
||||
第三步,确认和主张。
|
||||
|
||||
提炼完成之后,接下来就是确认和主张。确认主要是和自己的上级确认,得到上级的认同和支持后,就可以向团队内外进行主张了。当然,最好是在合适的场合,比如季度会、合作沟通会等,有计划、有步骤地把团队的职责和使命宣贯给大家。团队职能的设定和宣贯是一个长期工程,不要期待一蹴而就。当然,如果做得好的话,效果也很快就能显现出来。
|
||||
|
||||
以上,就是我对管理规划的第一个要素——职能的介绍。它是如此重要,以至于后面要介绍的其他三个要素,都要以此为核心。
|
||||
|
||||
那么,作为管理者,你能立刻说出你团队的职能定位吗?你们最重要的衡量指标是什么呢?
|
||||
|
||||
|
||||
|
||||
|
123
专栏/技术管理实战36讲/13如何为团队设定合理的目标呢?.md
Normal file
123
专栏/技术管理实战36讲/13如何为团队设定合理的目标呢?.md
Normal file
@ -0,0 +1,123 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
13 如何为团队设定合理的目标呢?
|
||||
管理规划有四个相互关联的要素:职能、目标、团队和路径。在上一篇文章中,我们已经探讨了第一个要素,也就是如何界定团队职能。我想现在你应该很清楚自己团队该承担什么样的基本职责,以及希望背负什么样的使命了。
|
||||
|
||||
那么,接下来的一个问题就是,未来的一段时间里,三个月、六个月也好,一年也好,你希望带着你的团队抵达一个什么样的目的地呢?这就是我们通常所说的“目标”。今天这篇文章我们就一起来看看目标到底该如何设定。
|
||||
|
||||
目标是个大话题,网上关于目标管理的文章数不胜数,公司里安排的目标管理培训一般也得讲一两天,而我这短短几千字的文章,能够带给你什么呢?我想是如下三点:
|
||||
|
||||
第一,你会更加清楚目标都意味着什么,它可不是让团队有事儿干那么简单。
|
||||
|
||||
第二,你会掌握目标设定的要点,即使你之前没做过目标管理,你也可以实际操作了。
|
||||
|
||||
第三,一起探讨在团队频繁调整,公司战略都不稳定的情况下,如何管理团队目标。
|
||||
|
||||
下面我就一一道来。
|
||||
|
||||
如果我问你,目标重要不重要?你可能会不假思索地说,重要!或者你会心里默默骂我白痴!似乎,目标的重要性是不言而喻的。那么我想问你一句,Why?为什么目标会那么重要?
|
||||
|
||||
对“Why”的回答里蕴藏着动力,我希望你做目标设定的时候,是基于你自己的动力,而不是被惯性推着走。那么,目标对于团队管理到底都意味着什么呢?
|
||||
|
||||
第一,最基本的,目标包含着你和上级的诉求,即,你们希望收获的东西。
|
||||
|
||||
第二,目标意味着资源的有效配置。明确的目标可以让你把资源投注在有效的方向上,从“该做什么”去调配资源,而不是“能干什么”。
|
||||
|
||||
第三,目标意味着执行力。很多管理者都把执行力和目标分开来谈,其实在我的访谈和观察中,技术管理者在任务执行上大多是很强的,并不是短板;而表现出“执行力不够”的最大的原因,都在于目标的不清晰或多变。我让他们回想自己做的执行力最棒的项目是不是都具有精确的目标,结果无一例外都是肯定的答案。显然,清晰的目标是高效执行的必要条件。
|
||||
|
||||
第四,目标意味着凝聚力。很多管理者问我到底该如何提升团队的凝聚力,我都会告诉他们:明确的团队目标和愿景,就是提升团队凝聚力的重要手段之一。大家因为相同的目标而并肩作战,在一起取得成就的过程中建立起深厚的“革命友情”,这对凝聚力有莫大帮助。
|
||||
|
||||
第五,目标也意味着激励。在提升员工自驱力的要素中,员工在工作中产生沉浸其中、物我两忘的“心流”状态,就需要有清晰的目标为前提。而且,团队目标感带给员工对工作的意义感和使命感,也是提升自驱力的重要来源。
|
||||
|
||||
你看目标有这么多的效应,是不是都想达到呢?但是,并不是随便一个目标就有这样的效果,只有合理的目标才有效。那么,什么样的目标才是合理的目标呢?你也许听很多人说过,“踮起脚尖能够到的目标最合适”,这句话太有道理了,可是怎么操作呢?
|
||||
|
||||
这就涉及到目标设定的原则,即“SMART”原则。分别对应着 5 个英文单词,即 Specific、Measurable、Attainable、Relevant 和 Time-bound,用中文来说就是目标的明确性、可衡量性、可达性、相关性和时限性。
|
||||
|
||||
前面提到的“踮起脚或跳一跳能够到的目标”,只是强调了其中的可达性原则,即,不能定一个完全实现不了的很高的目标,也不能定一个不需要努力就能实现的很低的目标。作为团队负责人,你会不会认为,定一个肯定能实现的相对保守的目标,对于向上级交差非常有利?
|
||||
|
||||
如果你真的这么想,那你就忽略了关于目标的一个重要的原则:目标是设定给团队的,而不是设定给上级的,其目的是为了让团队集中资源做出有效的成绩。当你为了容易交差而给团队设定一个没有挑战的目标时,团队成员是得不到激励的,也无法让员工进入“心流”状态。
|
||||
|
||||
另外,一个非常常见的情况是,如果你总让员工做没有挑战的工作,他很可能会因为没有成长而跟你提离职。所以,一个有挑战且努力能达到的目标,才是恰当的。
|
||||
|
||||
不过说老实话,对于技术出身的新经理来说,想让他把目标设定得激进些,是相当困难的,因为他做工程师时练就的“要靠谱”的价值观根深蒂固。所以,为了说到做到,而且保证高质量地完成,目标往往会定得比较保守。好在,管理是一门实践,意识到这一点后,就慢慢地调整吧!
|
||||
|
||||
说完可达性原则后,接下来,我们也探讨一下其他几个原则。
|
||||
|
||||
关于目标的明确性和可衡量性,我认为这两个原则是分不开的。“目标要明确”这句话,我相信你听得耳朵都磨出茧子了。那么究竟什么叫“明确”呢?我觉得你可以简单地理解为,把目标设定到可以衡量的程度,就叫做明确了。比如,下面两组目标说法的对比。
|
||||
|
||||
第一组:
|
||||
|
||||
a)“我们的目标是提升某个服务的性能。”这不是一个明确的可以衡量的目标。
|
||||
|
||||
b)“我们的目标是把某个服务的单机性能从 300qps 提升到 500qps。”这就是一个可以明确衡量的目标。
|
||||
|
||||
第二组:
|
||||
|
||||
a)“我们的目标是发布 BI 系统 1.0。”这看似是一个可以衡量的目标,但是 BI 系统 1.0 如何衡量是否完成了呢?又比较模糊。
|
||||
|
||||
b)“我们的目标是发布 BI 系统 1.0,支持 KPI 数据统计、全量数据导出功能。”这样就清楚 BI 系统 1.0 如何衡量了,要支持这样两项核心功能才行。
|
||||
|
||||
至此,想必你应该就清楚目标的明确性和可衡量性该如何操作了吧。
|
||||
|
||||
关于目标的相关性原则,对于技术团队来说很难跑偏,因为技术这个角色决定了其工作内容必定是和上、下游及上级目标相关联的。所以,在这儿我就不展开细讲了。
|
||||
|
||||
最后说说时限性原则。所有的目标都是基于一定时限的,缺少时间限制的目标没有意义。比如前面我们提到的“提升单机性能”的目标或“发布 BI 系统 1.0”的目标,如果没有限定一个时间,就不清楚该什么时候去衡量,也就无所谓是否有挑战和是否完成。
|
||||
|
||||
所以,一定要有个明确的时间点,比如“到 9 月底,把单机性能从 300qps 提升到 500qps”“到 12 月底,发布 BI 系统 1.0,支持 KPI 数据统计、全量数据导出分析功能”,就是两个完整且合理的目标描述了。
|
||||
|
||||
所以,当你要评判一个目标是否合理时,需要从 SMART 这五个原则去逐个审视,如果都符合了,说明你这个目标是清晰可行的。
|
||||
|
||||
|
||||
|
||||
目标的 SMART 原则
|
||||
|
||||
那么,目标的描述一般长什么样子呢?其实,就算是你没做过管理,也肯定不止一次地看到过自己团队的目标了,所以,我简要地做一个说明。
|
||||
|
||||
目标的描述形式,大体分为两类:一类是可以量化的指标,就是大家常说的 KPI(Key Performance Indicator,关键绩效指标);另外一类是不可量化的目标,用关键结果来衡量,就是我们常说的 KRA(Key Result Areas) 或 OKR(Objectives & Key Results),总之就是对关键结果的一种描述。
|
||||
|
||||
它们大体上的描述形式是:
|
||||
|
||||
KPI:到某时间点,什么指标达到什么数字;
|
||||
|
||||
KRA/OKR:到某时间点,完成什么工作,该工作实现了哪些功能或达到了哪些效果。
|
||||
|
||||
看起来,制定这样一个目标是不是挺简单?事实上,新经理在目标设定上,常常会踩一些坑,面临诸多挑战,如下四类问题和挑战是最为常见的。
|
||||
|
||||
第一类问题是基于现有资源做目标,而不是基于远方的目标往前推。这类问题常见的说法就是,“我们团队只能做到个程度”“这些项目能做完就不错了”等。其实,更为合理的做法应该是,从上级的角度来讲,你的团队需要保证哪几项重要的结果,然后再看看如何调配和补充资源。面对这类问题和挑战的钥匙叫做“以终为始的出发点”。
|
||||
|
||||
第二类问题是目标不明确。你可能会说,“从上面你说的来看,一个明确的目标很容易制定啊!”但问题在于,新管理者很少会因为“目标笼统或太大”导致不明确;不过,倒是常常会因为“过程化描述”而引发目标不明确的情况出现。
|
||||
|
||||
常见的说法是,“我们要在 10 月底,完成架构改造”“我们要在 12 月底,上线反作弊系统 1.0”等等。这类描述的问题在于,主要强调“我做了什么”,而没有交代做完这些工作后,“取得了什么效果”。 因此,面对这类问题和挑战的钥匙叫做“结果导向的描述”。
|
||||
|
||||
第三类问题是目标设定好之后,自己和自己的上级都很清楚了,但是没有刻意地向团队成员来传达,只是按照目标拆解去安排大家的工作。这样的做法,导致团队成员对于整个团队的方向感不清晰,那么前面我提到的那些目标能带来的效果就无法显现,比如起不到对团队的凝聚和激励的效果。面对这类问题和挑战的钥匙叫做“目标的向下同步”。
|
||||
|
||||
第四类问题,也是大家最头疼的一个问题,就是目标总是被迫变来变去。互联网领域很少有非常稳定的公司,业务总是在调整,自己的上级也时不时就换个新的,甚至于公司的战略也每隔一段时间就变一次。显然,之前为团队设定的目标,也得跟着变来变去。于是,目标慢慢变得形同虚设。面对这类问题和挑战的钥匙叫做“设定专业目标”,用专业目标来增强团队的内在定力。
|
||||
|
||||
团队和人是一样的,如果总是被外在需求牵着走,内心必然会充满焦虑,所以还需要弄清楚自己的内在追求。而专业目标,就是为团队树立明确的内在追求。
|
||||
|
||||
说到这里,你可能又会问:什么是“专业目标”呢?
|
||||
|
||||
要解释“专业目标”,我们就得先来谈谈“业务目标”。“业务目标”简单来说就是需要完成的业务业绩目标,也就是我们常说的 KPI 和 KRA,是公司和上级对你团队的业绩要求,这类目标一般是自上而下拆解下来的,所以来自于外部,一般不容易被忽略。
|
||||
|
||||
和“业务目标”来自外部要求相对应,“专业目标”来自你团队的内在要求,一般是由你和团队自己设定的,属于自我要求,所以新的管理者往往会忽略不做,有的是想不到,有的是懒得做。而恰恰是这个内在目标的设定,最能体现你的管理价值,因为这是最能展示你的自主性的地方。
|
||||
|
||||
专业目标设定的核心步骤就两步:第一,选择你要提升的关键维度;第二,设定目标,可以是量化的 KPI,也可以是非量化的 KRA。
|
||||
|
||||
关于团队的关键维度,上篇文章中我提到,就好像每个人都有自己的价值观一样,每个团队也都有自己最核心的评价维度,这是由团队职能决定的,比如服务端团队的稳定性和性能,数据团队的准确性和安全性,功能迭代团队的高效和质量,等等,这些维度是最能体现团队核心能力及价值的。
|
||||
|
||||
因此,即使上级没有提出要求,团队负责人也要为团队基于这些专业维度来设定目标,比如作为服务端团队,可以把“半年内提升 40% 的并发性能”作为团队的专业目标,以此来不断修炼团队的内功,并作为团队的内在追求。
|
||||
|
||||
如此,当外部的业务目标不稳定时,相对稳定的专业目标可以让团队内部一直有个“指南针”,从而降低目标频繁调整引起的员工焦虑,而且还避免了目标变来变去导致的“瞎忙”或“白忙”。
|
||||
|
||||
你可能会说,内在的专业目标还没有达成的时候,上级的业务目标又压下来了怎么办?这类冲突的处理办法和“重要紧急”四象限的权衡思路是一致的,内在的专业目标属于重要的事情,而外部压过来的目标,属于紧急的事情。重要紧急的权衡和决策是管理者的日常工作内容,慢慢你会有自己的心得体会的,现在我们先探讨的是“团队定力”的问题。
|
||||
|
||||
好了,到现在,你是否可以制定出自己团队的目标了呢?除了业务目标,你制定专业目标了吗?如果你已经有自己的团队目标,他们符合 SMART 原则吗?如果你都做得非常到位,你把这个非常棒的目标周知到团队每个成员了吗?
|
||||
|
||||
我期待,你通过对团队目标的驾驭,除了取得出色的业绩之外,还能打造出一个充满自驱力和凝聚力的高效执行的团队。
|
||||
|
||||
|
||||
|
||||
|
105
专栏/技术管理实战36讲/14如何来规划团队的组织结构呢?.md
Normal file
105
专栏/技术管理实战36讲/14如何来规划团队的组织结构呢?.md
Normal file
@ -0,0 +1,105 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
14 如何来规划团队的组织结构呢?
|
||||
管理规划的四个核心要素:职能、目标、团队和路径。前面我们已经探讨了职能和目标,想必此时,你应该很清楚自己团队的基本职责和使命了,并且已经为团队设定了清晰的目标。
|
||||
|
||||
那么今天,我们再来接着谈一谈,该如何做团队规划。
|
||||
|
||||
围绕着“团队”的工作非常多,我会在“团队建设篇”中详细阐述。现在,我们只是探讨团队规划,主要从如下三个视角:
|
||||
|
||||
第一个视角是看团队目标;
|
||||
|
||||
第二个视角是看资源;
|
||||
|
||||
第三个视角是看人才培养。
|
||||
|
||||
下面我就一一详细道来。
|
||||
|
||||
团队规划的第一个视角,是根据团队目标的设定去梳理团队。
|
||||
|
||||
如果说上一篇文章我们对于“目标”的探讨,主要聚焦在“业务目标”的话,那么本文我们探讨的团队规划,则包含了对“团队目标”的设定。这里的“团队目标”,不是指团队所要完成的业务目标,而是你希望在某个时间节点到来的时候,把团队发展成什么状态。换句话说就是,到那个时候团队会是什么样子呢?
|
||||
|
||||
对于某某人“长什么样子”的话题,你可能会从皮肤、样貌、身高、体重等要素来衡量。那么对于一个团队长什么样子,你要用什么指标来衡量呢?通常来说是如下三个:
|
||||
|
||||
首先是团队的规模。也就是你团队有多少人,这其中要理清楚有多少人是现有的,有多少人是接下来要新增的,即实际人数和预算人数,加起来就是你规划的团队总规模。
|
||||
|
||||
其次是团队的分工。即,你的团队都负责哪些业务,每个业务配置了多少人力,以及这些人员都如何分工,人力分布和业务目标是否匹配等。
|
||||
|
||||
最后是团队的梯队。一个团队的梯队情况代表了团队的成熟度和复原力。梯队成熟的团队,不会因为一些偶然的因素(比如某个核心员工休假,或者某个技术负责人离职等)就随便垮掉。复原力强的团队只是短暂影响部分业务进展,但是不会伤筋动骨、元气大伤,很快就会恢复正常。这个复原力很像技术服务的健壮性,会让团队非常有韧劲,经得起折腾。
|
||||
|
||||
综上,如果你从规模、分工和梯队三个要素来描述你团队的情况,就能看清团队的“样貌”了。
|
||||
|
||||
团队规划的第二个视角,是从资源角度来审视团队。
|
||||
|
||||
从资源视角来看待团队,是一个成熟管理者的标志之一。因为站在公司角度来看,每个团队都是一批人力资源,所以有个专门的职能角色叫 HR(人力资源)。
|
||||
|
||||
在现在很多互联网公司里,技术团队往往是最昂贵的资源和成本,预算人力,实质上就是预算资源。所以,作为一个管理者,在盘点自己当前人力和预算人力的时候,需要有成本意识,要考虑投入这么多资源和成本是否值得,是否合理。
|
||||
|
||||
其实,即便你不考虑这个问题,你的上级也会考虑,所以,你预算人力的时候,最好能给出十分充分的理由:为什么你需要这些人?为什么是这么多?你的依据和估算逻辑是什么?当然,你并不需要把所有的推演过程都汇报给上级,但是这并不意味着你不需要一个令人信服的推演逻辑,毕竟光靠“拍脑袋”肯定是不行的。
|
||||
|
||||
那么怎样才能够合理推算呢?
|
||||
|
||||
取决于你对业务的理解,以及你希望达成的目标。毕竟需要投入的人力和目标是息息相关的,和手段的选择也是密切相关的,换句话说你的各项决策都影响着资源的估算(下一篇文章我们会具体谈手段和路径的选择)。
|
||||
|
||||
可以参照行业资源配比情况。比如行业里产品、设计、开发、测试、运维等不同角色都有大体的比例,虽然不可照搬,但可用于参照,尤其是业务类型相似的。
|
||||
|
||||
团队规划的第三个视角,是从人才培养角度来看梯队规划。
|
||||
|
||||
关于对团队的盘点,除了团队的发展目标和资源投入视角,还需要从人才培养角度来看。即,到下一个时间节点,你需要重点培养出哪些人,给他们什么样的平台和空间,以及你有能力提供给他们什么指导和支持,期待他们能够胜任什么职能和角色。
|
||||
|
||||
一般来说,你重点培养的都是你团队最核心的人,也包括最有潜质的人,但是一般只涉及你的直接下级和他们的个别下级这两层,其他层次的人才培养则是你下级管理者的职责。当然,对于新经理来说,只需关心自己的直接下级就可以了。
|
||||
|
||||
关于人才的选拔和培养,我们会在后面“团队建设”相关的章节中详细探讨,这里我们就先了解做规划的时候,要涵盖重点人才的培养目标,就可以了。
|
||||
|
||||
关于新人的培养和引进,这里提出一个新概念叫“团队消化能力”。鉴于团队现实的梯队情况和新人导师的精力问题,一个团队能够良性吸纳的新人是有限的;如果新人引进过快,就会快速冲淡当前的团队状态,就和新组建一个团队差别不大了,这时很多新经理会顾此失彼,团队也近乎失控。
|
||||
|
||||
所以,这主要看你的取舍。有的管理者倾向于有步骤、有节奏地发展,而有的管理者迫于业务压力,也就不考虑团队消化能力了。这些做法无所谓谁对谁错,只是因人而异罢了。但是无论做哪种选择,考虑你团队能消化多少新人,是你做团队规划时需要关注的一个问题。
|
||||
|
||||
那么如何估算团队消化能力呢?
|
||||
|
||||
不可否认,带新人是需要花费老员工一些时间和精力的。所以要看看你团队都有谁能带人,分别带几个比较合理。所谓合理,就是需要兼顾他们对业务的投入。
|
||||
|
||||
看看你团队的新人培养机制是否成熟健全。如果你团队有成熟的新人入职培养机制和熟悉业务的学习资料,那么能同时消化的新人就会多一些。所以,作为一个“踏实”的管理者,把这些基础的管理工作做起来,对于团队的长线发展是很有好处的。即便你的直接上级是个“急功近利”的老板,你也可以有自己的管理风格,不是吗?
|
||||
|
||||
上面我们从三个视角探讨了做团队规划的逻辑和要点,那么,如果真的要给上级提交一份规划报告,关于团队部分,你应该以什么形式来呈现呢?
|
||||
|
||||
我建议你要以你和上级约定俗成的习惯和形式来呈现。假如你们还没有明确的要求和约定,那么你可以参照下面的形式,大体上也是三个部分。
|
||||
|
||||
第一部分,绘制一张组织结构图。这张图需要体现我前面提到的团队状态三要素:
|
||||
|
||||
规模,包括当前人数、预算人数和总人数。
|
||||
|
||||
分工,体现团队人力都分布在哪些业务上,以及各个业务都由谁来负责。
|
||||
|
||||
梯队,包括团队的级别和梯队分布情况。
|
||||
|
||||
|
||||
|
||||
组织架构图示例
|
||||
|
||||
第二部分,列出整个团队的资源盘点情况。大体是这样的:
|
||||
|
||||
A 级别:x 人,其中当前 m 人,预算新增 n 人;
|
||||
|
||||
B 级别:y 人,其中当前 m 人,预算新增 n 人;
|
||||
|
||||
C 级别:z 人,其中当前 m 人,预算新增 n 人;
|
||||
|
||||
……
|
||||
|
||||
第三,列出重点培养对象,以及负责业务。大体是这样的:
|
||||
|
||||
张三,XX 业务核心工程师,到年底能完全负责 XX 业务,并能带新人;
|
||||
|
||||
李四,YY 业务负责人,到年底能带 n 人独立负责 YY 业务;
|
||||
|
||||
……
|
||||
|
||||
怎么样,团队规划的呈现很简单吧?所以,核心还是对规划要点的思考和梳理,经过上面的探讨,你是否可以轻易地盘点自己的团队了呢?欢迎你留言分享和交流。
|
||||
|
||||
|
||||
|
||||
|
91
专栏/技术管理实战36讲/15我都要申请哪些资源呢?.md
Normal file
91
专栏/技术管理实战36讲/15我都要申请哪些资源呢?.md
Normal file
@ -0,0 +1,91 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
15 我都要申请哪些资源呢?
|
||||
做管理规划,无论你是想评估团队的投入产出,还是给上级做工作汇报,都有一个必要的内容,就是要弄清楚,你需要投入多少资源。而投入多少资源,除了和希望达成的目标相互匹配,还和你选择什么样的路径和手段息息相关。
|
||||
|
||||
接下来,我们就集中探讨一下管理规划的第四个要素:路径选择和资源申请的问题。
|
||||
|
||||
可能很多一线技术管理者会说,我需要考虑的资源类型非常单一,基本上每次申请资源都是增加人力,这没有什么难的。我想说,增加人手没有问题,只是在采用“增加人手”这个方案之前,你是否考虑到如下的三个问题了呢?
|
||||
|
||||
第一个问题,你是否了解资源的丰富性呢?
|
||||
|
||||
一提到资源申请,人们大多会想到的是人、财、物这三大项。对于做技术团队管理的你来说,“人”,是最常见的资源。而且,“财”和“物”的预算一般也围绕着团队的人数来做,比如团建费用、培训费用、差旅费用、办公设备等等,都是基于团队人数来预算的,整体上并不复杂。
|
||||
|
||||
但这里我需要提醒你的是,还有其他几类资源也需要关注,可不要忽略。
|
||||
|
||||
首先是时间。很多管理者会忽略时间这个最重要的资源。对于任何一项工作,你预算多少人和你预算多少时间是分不开的。所以,做规划的时候,也需要了解上级对于各项工作的时间预期是什么样的。这意味着,上级允许你花多少时间来做这些工作。
|
||||
|
||||
千万别认为,上级批准了你的人力预算就等于给了你充足的资源,因为还得看看上级给了你多少时间。而且,上级固然有上级的期待,但你还是得有自己的判断,因为你最清楚各项工作的具体情况,需要综合你对紧急重要程度的理解做出判断。所以,请把时间当做资源来看待,这样你会更加清楚对于投入的理解。
|
||||
|
||||
其次是信息。信息资源,是另外一个常被忽视的资源。有的时候,你需要更多的公司内外的信息,可能是业务的,也可能是人员的;你的工作如果需要特殊的信息和数据,需要提前和上级沟通,寻求必要的支持。
|
||||
|
||||
最后是权限。和信息资源类似,也是出于做好某项工作的目的,你可以看看需要开通哪些之前不具备的权限,以及这些权限是否可获得。比如有的公司一线管理者是有沟通绩效权限的,而有的公司则不允许。如果你要把绩效作为重要的人才培养和激励手段的话,就得考虑你能否获取这样的权限。
|
||||
|
||||
类似的还有,你是否拥有使用奖金激励的权限,你是否被允许参加某个会议的权限等,这都可以是你要关注的资源。
|
||||
|
||||
所以你看,除了人、财、物,你还需要很多资源的支持,所以当你评估一个平台是否有发挥空间时,可不只是看职位高低,人员多寡。你能否得到全方位的支持,也是很重要的因素。当然,前提是你知道自己需要什么。
|
||||
|
||||
第二个问题,你是否意识到手段的多样性呢?
|
||||
|
||||
工程师出身的管理者,“炫技”的情况比较常见,其中一个显著特征就是,只有自己开发的作品才是最好的,一有机会就重构,因为,“前人写的东西实在是太烂了,不能忍受”,崇尚亲力亲为,凡事自己开发。所以,一旦有大的新需求,用他们的话说,那得“招聘一些工程师才能做”。
|
||||
|
||||
站在工程师视角上,追求工作的极致品质,恰恰是一种良好的工匠精神。但是站在管理者视角上,就需要评估一段时间内的产出效率了。衡量一项工作“到底需要花 5 天做到 70 分,还是 10 天做到 90 分”,是管理者的日常工作。90 分方案未必就比 70 分方案好,此时,就需要优秀工程师出身的你放弃一些执念了。一旦放松这个念头,你就会发现,完成一项工作,原来还有很多的手段可以选择。下面我就来列举一些。
|
||||
|
||||
比如你想做一个新功能,诸如“人脸识别”“自动推荐”“反作弊”等。以下的做法是不同的管理者所采用过的:
|
||||
|
||||
在不同的公司、不同的期待之下,不同的管理者会做出不同的选择。这不同的选择会带来不同的效果,同时也意味着不同的成本。
|
||||
|
||||
对于自学自研来说,由于靠自己团队的力量,资金开销比较低,维护成本也可控;而由于需要边学边做,时间成本会比较高。
|
||||
|
||||
对于招聘来说,不确定性比较高,招聘顺利固然好,但招聘不顺则时间完全不可预期,整体上时间成本比较高。
|
||||
|
||||
对于人才借调来说,如果能借调到合适的人,各方面的成本是最低的,但是需要这个事情足够重要才能获得支持。在中大型公司里的管理者,可以把这个方法作为可选路径之一,而早期公司,一般并不具备这个条件。
|
||||
|
||||
对于跨部门合作来说,项目推进的可控性取决于合作情况,这里最大的风险就是合作成本能否控制住。
|
||||
|
||||
对于外包来说,时间和资金成本一般都可控,用来做尝试性项目或者 demo 是比较合理的。但如果是长期的任务,你会发现外包的解决方案可维护性比较差,迁移和替换的成本会比较高。
|
||||
|
||||
采购云服务,对于中小公司来说,其实是很好的解决方案,对人才成本、维护成本、时间成本,都可以降得很低,特别适合初创公司,所以你看业内的云服务层出不穷,确实有价值。
|
||||
|
||||
买方案,是时间成本很低,资金成本略高的一种方案。在应急的情况下,或者是公司非核心业务的场景下,这倒不失为一种好的解决方案。
|
||||
|
||||
以上的说法和判断,是我基于我之前的团队情况给出的。那么对于你来说,不同的方案意味着着多大程度的成本呢,你可以尝试把你认为的“大”“中”“小”填入下表中。这个表格最大的意义不在于让你去评估每一种方案的成本大小,而在于扩展你的管理思路,看到解决问题手段的多样性,避免思路过于单一,就达到目的了。
|
||||
|
||||
|
||||
|
||||
手段 - 成本盘点图
|
||||
|
||||
第三个问题,即人力资源的持续性。通俗说就是,不是所有的人力短缺,都要通过招聘来解决。
|
||||
|
||||
在我给互联网公司做技术管理咨询的过程中,遇到不少中小型公司的技术负责人或创始人,动辄让我帮忙介绍某技术领域的资深专家。他们常常会这样跟我说:
|
||||
|
||||
说法 1:“对于我们这个业务来说,数据很重要,我需要搭个数据团队,能帮我介绍一位数据大牛吗?”可实际情况是,自己连数据需求都描述不清楚,只是直觉上认为这能给公司带来价值,其实每天的数据量,拉个表格都能看清楚了。
|
||||
|
||||
说法 2:“我们接下来要做智能推荐系统,得招两个专门做推荐算法的。”但实际情况是,大部分数据都是格式化数据,却连最基本的推荐策略都还没做,还远远达不到专业瓶颈。
|
||||
|
||||
说法 3:“我们需要招两个做专业图像处理和模式识别的。”但实际情况是,公司业务的核心竞争力在于 O2O 业务,而不在于图像处理技术。
|
||||
|
||||
以上的这些说法,显然,他们太高估招聘能解决的问题了,而且太低估人才选用育留的成本了。事实上,牛人一般会嫌业务量小、平台小招聘不来,即便来了,成天形单影只的,也未必留得住。所以,招聘作为一种迟缓的解决问题的手段,更多地是看长线是否需要。
|
||||
|
||||
对于工程师思维特别重的管理者来说,他们尤其倚重技术;对于不懂技术的管理者来说,他们又特别迷信技术。而职业的技术管理者,就需要在这之间找到一个平衡,提供一个既能够解决问题,成本又合理的可操作的执行方案,而不是一个“走一步算一步”的对策。
|
||||
|
||||
以上的三个意识如果你都具备,能够从资源丰富性、手段多样性和人才持续性来预算你的资源,说明你已经是一位老道的管理者了。我们通常会说,管理者要做战略,所谓战略是什么呢?其实就是筹划把资源投在什么方向,以达成什么目标。所以,资源视角就是战略视角。
|
||||
|
||||
至此,我们探讨完了管理规划的全部四个要素:职能、目标、团队和路径。细心的你也许会发现,探讨路径以及预算资源的时候,离不开目标和团队;而盘点团队的时候,又脱不开目标和路径;而设定目标的时候,也需要基于当前团队的情况和可用资源。
|
||||
|
||||
也就是说,尽管我们是把目标、团队、路径分开来探讨的,但是这几个要素之间并不是割裂的,而是相互联系的。所以,只有你把这三个要素统筹起来,梳理明白,才能“产出”一份完整的管理规划。
|
||||
|
||||
|
||||
|
||||
“规划四要素”关系图
|
||||
|
||||
本文是“管理三部曲之管理规划篇”的最后一篇文章,整个“管理规划篇”其实都围绕着同一个主题展开,那就是弄清楚团队工作的方向问题。相信通过这几篇文章的探讨,你已经很清楚做一份管理规划都需要考虑哪些要素,以及各个要素的操作要点了。
|
||||
|
||||
那么,你现在有信心为自己的团队做一个清晰的规划了吗?
|
||||
|
||||
|
||||
|
||||
|
127
专栏/技术管理实战36讲/16团队建设该从哪里入手?.md
Normal file
127
专栏/技术管理实战36讲/16团队建设该从哪里入手?.md
Normal file
@ -0,0 +1,127 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
16 团队建设该从哪里入手?
|
||||
上个月,我给一个技术团队的整个管理层做了一场培训。在需求调研的时候,我问技术团队的总负责人:“你期待通过这个工作坊,解决什么样的问题,并收获什么样的效果呢?”
|
||||
|
||||
他认真地跟我说:“我希望能够让管理者了解到,如何群策群力打胜仗!”紧接着,他又补充说:“CEO 也是这么期待的。”
|
||||
|
||||
听他这么说,我第一反应就是,高管就是高管,说话高屋建瓴,直达要害。我们做管理工作的目标,归根结底,不就是“群策群力打胜仗”吗?“群策群力”就是如何带好团队,“打胜仗”就是如何取得好的业绩,“带人”+“做事”,齐了。可问题是,具体从哪里着手呢?
|
||||
|
||||
做具体的管理工作,和做一场培训是相通的,都需要有针对性的目标。“群策群力打胜仗”是终极目标,但还是不知道要解决什么问题,于是我接着问他:“你希望通过解决或改善什么问题,来更好地实现‘群策群力打胜仗’这个目标呢?毕竟这是每位管理者的理想,那么具体到你的团队,你希望着手做哪几件事呢?”
|
||||
|
||||
他若有所思,然后跟我说:“团队的经理大部分都是工程师转的管理,即便有人已经带过几十人的团队了,却还是不太清楚管理都该做哪些事情,有时候还没有把自己放在管理角色上来看待工作中的问题;另外呢,我们这些管理者彼此间也需要更好地融合,大家合作的时间并不长,凝聚力还不太够……”
|
||||
|
||||
我试着总结道:“听下来,你是希望通过做这样两件事,来更好地群策群力打胜仗:第一,提升管理者的角色认知,让他们清楚自己作为 leader 都要做哪些工作;第二,是团队融合,你希望工作坊之后,经理间有更好的互信和默契。”
|
||||
|
||||
他连连点头说:“对对对,就是这个意思……”
|
||||
|
||||
于是,我再一次地看到,对于管理者来说,“管理”是多么复合的一个词汇,它包含太多层次和维度,每位管理者都会有自己不同的理解和表述。做管理工作,如果仅凭感觉泛泛地去做,效果是很难预期的。因此,对于管理工作来说,有哪些具体的切入点,可以让管理者围绕这些“切入点”去开展工作,是非常值得探讨的。
|
||||
|
||||
关于管理者都需要做哪些工作的问题,我在前面的文章已经给出了一个管理框架,我把它称为“管理三明治”。如果你还记得的话,这个“三明治”有三根“火腿肠”,对应管理者的三项日常工作:“管理规划”“团队建设”和“任务管理”,用通俗的话来说,就是“看方向”“带人”和“做事”。今天呢,我们把镜头拉到第二根“火腿肠”,聚焦讲讲如何“带人”。
|
||||
|
||||
|
||||
|
||||
“管理三明治”
|
||||
|
||||
“带人”,其实就是我们常说的“带团队”“团队建设”。显然,所有的团队都需要有目标和方向感,也都需要在任务执行的过程中去锤炼和打磨,和“看方向”“做事”这两根“火腿肠”脱不开关系。但是,我们今天仅就“团队”来做一些探讨。
|
||||
|
||||
那么,究竟怎么带好团队呢?带团队需要从哪几个维度去展开工作呢?我采访过一些新经理,也采访过一些二线经理,大家的说法各不相同,这让我深感意外,似乎又在情理之中:
|
||||
|
||||
有人说:“带团队的核心是要做好人才培养。”
|
||||
|
||||
有人说:“最重要的是把合适的人放在合适的位置上。”
|
||||
|
||||
有人说:“对团队来说,最重要的是梯队和氛围。”
|
||||
|
||||
有人说:“一个好的团队是各有所长,协同配合。”
|
||||
|
||||
有人说:“激励很重要。”
|
||||
|
||||
有人说:“团队凝聚力很关键。”
|
||||
|
||||
有人说:“经理要以身作则。”
|
||||
|
||||
……
|
||||
|
||||
虽然说法不一,但每个人说的都有道理,蕴含着真知灼见和各自的管理精髓,每一个真知灼见都能在我脑海中点亮一颗明星,以至于我眼前出现了姜子牙封神时的情景,天空中的星星一颗颗亮起来,越来越多,越来越多……
|
||||
|
||||
突然之间,我一时有些眼花缭乱、不知所措。我到底该去摘哪一颗呢?有没有一个“星空图”,能够把这些散落的繁星连接成一幅有意义的图画呢?那样我就可以按图索骥去寻找我需要的星星了。
|
||||
|
||||
作为一个有追求的工程师出身的管理者,散落一地的经验是不能令我满意的,我一定要找到“带团队”这个主题的系统性框架,然后把这些宝贵的经验都安放进去。
|
||||
|
||||
好,既然要研究如何“带团队”,我们就先来好好分析分析“团队”这个研究对象。
|
||||
|
||||
为了容易理解,再次搬出我前面提到的“马车模型”,当下我们研究的是团队,也就是“马车模型”中拉车的“马队”,我们就来分析分析这个“马队”。
|
||||
|
||||
|
||||
|
||||
奔跑的马车
|
||||
|
||||
我们看到,观察一个马队,至少可以从三个层次来看:
|
||||
|
||||
第一个层次,就是单个的马,马队是由一匹一匹的个体的马匹组成的;
|
||||
|
||||
第二个层次,个体马匹和个体马匹之间是有连接的,如果没有连接在一起,它们就不能作为拉同一辆车的马;
|
||||
|
||||
第三个层次,马队是有其整体性的,马队的规模,马队的气势,马队整体的耐力等等。
|
||||
|
||||
这样,我们就把“马队”这一研究对象拆解成了三个子对象:“马匹个体”“马匹之间”“马队整体”。接下来,我们继续剖析。
|
||||
|
||||
首先,我们从“马匹个体”来看。
|
||||
|
||||
一个好的马队,每匹马都应该是奋力向前的。如何才能奋力向前呢?这里包含两个要素:
|
||||
|
||||
力气。首先一匹马本身得有力气,这是马车前进的基础。如何让一匹马有力气就是一个好的工作切入点。如何提升马匹的力气或体能,这对应到团队工作中,就像如何培养员工的工作能力一样。
|
||||
|
||||
意愿。只有力气是不够的,要让马匹奋力向前,除了“力气”,还得有意愿,就是得给马匹一个理由,让它愿意使劲地拉车。这对应到我们的团队工作中,就是员工激励:去提升员工的工作意愿。
|
||||
|
||||
还有没有其他要素呢?可能有,但是对于个体角度的工作来说,“能力 + 意愿”,已经足够。
|
||||
|
||||
接下来,我们把“马匹之间”这个层次,也来解析解析。
|
||||
|
||||
显然,每匹马都奋力向前,车就一定会跑得快吗?除了马匹个体用力,还有什么要素会影响车的速度呢?也有两个:
|
||||
|
||||
马队的阵型,即排兵布阵。说白了就是,马和马之间是用什么结构连接起来的,这决定了各匹马用力的方向是什么。即便两匹马都很拼命,但是如果它们往两个相反的方向用力,马车也是不动的。具体到我们的团队,就对应到人员分工上。正常情况下,我们都不会做出相反的分工,但是如果对于同一件事情,一个员工在努力地赶进度,而另一个员工在拼命追求质量,那么显然他们是在往不同的方向努力。所以分工不是简单地“谁做啥”的问题,还包括是否有相互统一的评估维度。
|
||||
|
||||
节奏和默契。如果阵型结构能保证所有马匹往一个方向努力,车就会快了吧?未必,还有一个要素需要考虑,就是马与马之间,有没有一致的节奏和良好的默契,这也是很重要的。具体到我们的团队就是,团队成员间有没有很好的信任和默契,协作上是否高效顺畅,是不是只需要只言片语、一个眼神、一个手势就能心领神会。这也决定了我们团队这架马车能跑多快。
|
||||
|
||||
除此之外,“马匹之间”还有哪些要素要考虑吗?在我看起来,如果把“分工”和“协作”搞好了,就已经抓住了最核心的要素。
|
||||
|
||||
最后,我们再来看“马队整体”这个层次。
|
||||
|
||||
如果说我们研究“马匹个体”,是为了搞清楚如何让“马跑得快”;我们研究“马匹之间”的构造,是搞清楚如何让“车跑得快”;那么我们研究“马队整体”,主要是想看看,如何才能让马车“一直跑得快”,或者说,跑得远,也就是团队的耐力和可持续性问题。
|
||||
|
||||
我们可以从外部来给团队很多的激励,比如愿景目标和使命,比如带团队做出好的业绩和大的成就,这些方面呢,我们会在管理规划和任务管理这两根“火腿肠”中探讨。今天,我们仅从团队角度来看,如何提升团队的耐力。
|
||||
|
||||
也是两个要素:
|
||||
|
||||
马队构成 vs 团队梯队。从这个角度来审视马队,对应到团队就是梯队,盘点团队新老强弱的构成。团队工作是着眼长线的工作,我们不是只赶一段路。一个团队如果没有良好的梯队,只是靠一两个成熟的高手在支撑,那么一旦这一两个高手请假、调走或者离职,整个团队就瘫痪了。所以,要把团队的战斗力放在一个更长的时间区间去考虑。
|
||||
|
||||
马队展现出来的气势和精神面貌 vs 团队文化。团队文化如果你觉得难以捉摸,也可以叫“团队氛围”,总之就是团队成员能够在这里找到非常好的认同感,大家也非常清楚在这个团队里,什么是重要的,什么是不重要的,什么是应该的,什么是不应该的,都不需要去一点一点交代。我们可能平时也不会特别注意到,但是却无处不在。一个公司因为文化发生变化而带来的团队动荡,是灾难性的、难以缓解的,所以不能忽视团队文化的建设。
|
||||
|
||||
综合上面我们对“马队”3 个层次的解析,就得到了团队建设时 6 个维度的工作要素:
|
||||
|
||||
针对员工个体的两个要素是:能力和激励;
|
||||
|
||||
针对员工个体之间的两个要素是:分工和协作;
|
||||
|
||||
针对团队整体的两个要素是:梯队和文化。
|
||||
|
||||
|
||||
|
||||
团队建设六要素
|
||||
|
||||
这样,你就知道了,虽然“带团队”是个无处下手的大概念,但是你可以着眼这 6 个要素去开展工作,是不是感觉清楚多了呢?
|
||||
|
||||
当然,你可以用自己认为更贴切的词汇和术语,去替换这 6 个要素的具体叫法。但是从这 3 个层次来审视你的团队工作,以及从 6 个要素去积累你的管理方法论,你是不是就看到满天繁星中的那个“星空图”了呢?
|
||||
|
||||
关于每一个维度或每一个团队建设的要素,我会在后续的文章中逐个来探讨,如果你今天能收到团队建设的一个工作框架,就很棒了,不是吗:)
|
||||
|
||||
现在,如果有人问你如何提升团队的战斗力,你清楚该怎么答复了吗?欢迎给我留言,我们继续探讨。
|
||||
|
||||
|
||||
|
||||
|
135
专栏/技术管理实战36讲/17如何提升员工的个人能力?.md
Normal file
135
专栏/技术管理实战36讲/17如何提升员工的个人能力?.md
Normal file
@ -0,0 +1,135 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
17 如何提升员工的个人能力?
|
||||
上一篇文章,我们系统地探讨了如何提升一个团队的战斗力,并从中明白了这样一个简单的道理:提升团队战斗力的基础和前提,是提升员工的个体能力。显然,如果一个团队中员工的个体能力都不提高,整体的战斗力又如何提上去呢?
|
||||
|
||||
首先需要澄清一下:虽然我把个体能力这个要素放在了第一个来讲,而且也反复强调了个体能力是团队战斗力的基础,但是这并不意味着,当你要提升团队战斗力的时候,就必须先从这个要素下手。而应全面 review 团队建设六大要素,看看从哪个着手对你来说是事半功倍的,就从哪个要素去着手。如果恰好员工个体的工作能力是当务之急,那么,希望这篇文章可以带给你一些启发。
|
||||
|
||||
要探讨如何提升员工的能力,第一个要回答的问题就是:你要提升员工的什么能力?
|
||||
|
||||
“工作能力”这个概念看似具体,其实在沟通中会产生很多误会和分歧。那么工作能力到底有哪些呢?这里我介绍一下关于“能力”的两个最常见的划分方法。
|
||||
|
||||
第一个分法,就是在这个专栏的第 7 篇文章中,我们探讨“管理自信”时提到的“能力三核”,把人的能力分为知识、技能和才干三个层次(具体可以参看专栏文章 07)。如果我没有说错的话,大部分管理者希望员工提升的能力,是在“技能”这个层次,也就是员工能操作和完成的技术,比如快速学习能力、进度控制能力等。
|
||||
|
||||
|
||||
|
||||
“能力三核”
|
||||
|
||||
第二个分法,是把做好一份工作的能力分为人格力量、专业能力和通用能力(如下图)。
|
||||
|
||||
|
||||
|
||||
工作能力三维视图
|
||||
|
||||
人格力量通常是指一个人在面对某一情形时稳定的态度和表现,比如迎难而上、坚持不懈、积极正向、主动担当等等。这些人格力量对于个人能否搞定一件事情有时至关重要,但是培养起来却不是一朝一夕的,关键在于平时。
|
||||
|
||||
专业能力很容易理解,对于技术人来说,一般就是指技术能力。很多公司都有技术能力衡量标准和体系,用于评估工程师的技术水平。创业公司即使不会明文规定和实施这样的技术职级体系,但是一般也会参照这些大公司的要求和标准。所以,工程师专业能力的评价维度和标准相对于通用能力更加有据可循。
|
||||
|
||||
通用能力,每个人都会常常提起,但是很少有人能说清楚哪些能力算是通用能力。依我之见,你不需要去弄清楚这个模糊的概念,你只需要去定义一些你团队所重视的通用能力就好;入选你“通用能力清单”的这些能力,可以有效地帮你的员工做好工作。比如我会把沟通表达能力、团队协作能力、快速学习能力等作为重要的通用能力,并和我的团队达成共识。
|
||||
|
||||
通过上面的分层次探讨不难发现,提升员工个人能力的重点,会放在工作技能层面,包括专业能力和通用能力。
|
||||
|
||||
那么,要把这些能力提升到什么水准呢?或者说,其中的哪些能力够用就好?哪些能力要持续不断地提升呢?
|
||||
|
||||
关于这个问题的答案,我得先请你回答一个问题:你提升员工个人能力的初衷是什么呢?
|
||||
|
||||
你也许会毫不迟疑地回答说:“当然是为了做好工作了,这还有什么疑问嘛!”
|
||||
|
||||
其实,我们对于一个人的评价,从来都是有双重标准的,一个标准是“及格”,另外一个标准是“优秀”。所谓“及格”,就是只要胜任工作的要求就好了;而“优秀”,除了胜任工作要求,还需要脱颖而出,超出团队普通表现,成为整个团队的核心人物。
|
||||
|
||||
对于有些员工,你对他们的期待是把交代给他们的工作做好即可,所以侧重于提升他们的专业技能,以达到专业能力的硬指标,目标是“胜任”,也就是上面我们提到的“及格”,这是你期待的下限。
|
||||
|
||||
而对于另外一些员工,你对他们的要求和期待就不只是做好本职工作那么简单了,你还希望他们经过培养之后,能成为团队里的顶梁柱,这是你期待的上限。在这样的初衷之下,你不但对他们的专业能力要求高,还会对很多通用能力做出要求,比如目标管理、沟通协作等等,你甚至会为他们量身打造一个培养计划。
|
||||
|
||||
显然,不同的初衷决定了你制定什么样的标准,然后把这个标准写入员工的 IDP(个人发展计划),并双方达成一致,这就形成了个人能力提升的目标,是你们直接的一个“合作协议”。
|
||||
|
||||
接下来,我们就聊聊,如何达成这个目标。
|
||||
|
||||
关于做哪些事情来帮员工提升个人能力,相信你会有自己的经验和偏好。但也不外乎“7-2-1”法则,即:10% 靠听课和看书自学,20% 靠相互交流和讨论,70% 靠工作实践。我们可以按照这个思路去盘点一下常见的学习方式或方法。
|
||||
|
||||
第一类,关于帮助员工自学。对于管理者来说,常见的做法有:
|
||||
|
||||
组织员工参加培训;
|
||||
|
||||
为员工推荐和购买书籍;
|
||||
|
||||
提供学习文档、视频等;
|
||||
|
||||
……
|
||||
|
||||
第二类,关于相互交流讨论。对于管理者来说,常见的做法有:
|
||||
|
||||
组织兴趣小组、读书会等;
|
||||
|
||||
技术分享交流会、代码评审会等;
|
||||
|
||||
重点工作复盘,即 case study 等;
|
||||
|
||||
……
|
||||
|
||||
第三类,关于工作实践。对于管理者来说,常见的做法有:
|
||||
|
||||
授权和辅导。给员工独立负责重要工作的机会,并给予辅导和反馈。
|
||||
|
||||
调研工作项目化。即把调研学习的工作进行项目化管理。
|
||||
|
||||
总结并内化。对于员工完成的重要工作,有必要请他们做一个工作总结,看看从中学到了什么。员工在这个总结和反思过程中的收获,甚至比总结的结果本身更重要。
|
||||
|
||||
……
|
||||
|
||||
你还使用了哪些具体的方法吗?欢迎给我留言继续交流。
|
||||
|
||||
接下来,我们探讨一个很重要的话题。你有没有发现这样的一个情况,对于提升员工个人能力来说,最关键的往往不是学习的方法,而是学习的意愿。对于很多团队来说,并不缺少学习的机制,而是没有能够有效激发员工的学习动力。主动学习的员工总会是少数派,不只是公司的员工如此,社会生活中的人们亦是如此,所以有人说,“学习是反人性的事情!”
|
||||
|
||||
那么,作为管理者,你应该如何激发员工学习的动力和意愿呢?大体上可总结为如下三板斧:“推”“拉”“放手”。
|
||||
|
||||
所谓“推”,就是给压力,推着他们学。
|
||||
|
||||
提出明确的工作要求。比如,在 1 周内熟悉某个业务并可以做开发。
|
||||
|
||||
设置学习机制。也就是强制要求遵守学习规则,并完成学习任务。
|
||||
|
||||
peer pressure。团队整体学习成长的氛围,会给不学习的员工带来压力。
|
||||
|
||||
惩罚。包括从绩效等级、晋升机会、调薪幅度等等,对于学习意愿低的员工有适当的“关照”。
|
||||
|
||||
所谓“拉”,就是给方向,引导他们学。
|
||||
|
||||
树立榜样。把特别有学习意愿和成长快速的员工设为标杆人物,在团队内给予认可和奖励。
|
||||
|
||||
配备导师。有明确导师的新人和员工,更愿意请教问题并快速融入团队。也许有的管理者会说,“我们团队氛围很好,新人来了随便问谁都可以。”而事实上,有名义上的导师,比没有指明导师要好很多,“找谁都行”,即意味着没有人对此负责。所以,请为你团队成员配备导师,新人导师最好是团队内的,而资深员工的导师,可以找团队外更资深的人。
|
||||
|
||||
给地图。成熟的公司往往会有技术方面的“技能图”,作为管理者,你也可以为自己团队制定一个成长的“技能图”,并标记出重要等级。这样,团队成员就有了学习和成长的方向,知道该往哪里使劲了。
|
||||
|
||||
所谓“放手”,就是给发挥空间,让他们自主学习。
|
||||
|
||||
给员工勇挑重担的机会。在风险可控的情况下,给员工承担责任的机会,让他们去负责一些有挑战的工作。
|
||||
|
||||
给员工自主空间,让他们独立思考,独立决策。你的辅导仅限于在他们的决策之后给出看法和建议。
|
||||
|
||||
给员工信心和耐心,允许他们犯错、走弯路。因为很多经验都是踩坑儿踩出来的,所以不能一出问题就劈头盖脸一顿批,甚至是剥夺其做事的机会。
|
||||
|
||||
通常来讲,通过“推”“拉”“放手”,就可以激发很多员工的学习动力了,你甚至可以把学习和成长放入团队文化建设当中。当然,如果你要把学习作为团队文化的一部分,那就需要你自己首先有学习的“基因”。
|
||||
|
||||
最后,关于提升员工的能力,有两个信念特别重要。
|
||||
|
||||
第一是相信员工能力的差异性。即看到差异,重视丰富性。在工业时代,整齐划一、严格服从是团队管理的哲学;而在知识经济时代,员工的创造力能为团队带来更大的价值。创造力往往来源于差异的碰撞,所以作为管理者,你要特别关注能力的丰富性,标准不能太单一。
|
||||
|
||||
第二是相信团队能力的系统性。即欣赏差异,重视互补性。员工能力的差异,往往是他们对于团队的独特价值所在,管理者就是要像一位音乐指挥家一样,把各种优势各异的人统筹在一起,演奏出美妙的乐章。正如优势理论中所说的,所谓完美的团队,就是价值观相同,优势互补的团队。所以,作为管理者,你要看到团队能力的系统性,不要把各个员工的能力割裂来看。
|
||||
|
||||
好了,对于如何提升员工的个人能力这个话题,我们就先聊到这儿。归结起来无非就是三个步骤:
|
||||
|
||||
首先,定义你所谓的员工能力;
|
||||
|
||||
其次,设计出一些可行的方法;
|
||||
|
||||
最后,激发员工的学习动力。
|
||||
|
||||
你还有哪些好的经验和体会吗?欢迎留言分享。
|
||||
|
||||
|
||||
|
||||
|
167
专栏/技术管理实战36讲/18如何提升员工的工作意愿和积极性?.md
Normal file
167
专栏/技术管理实战36讲/18如何提升员工的工作意愿和积极性?.md
Normal file
@ -0,0 +1,167 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
18 如何提升员工的工作意愿和积极性?
|
||||
前面我们提到,一个团队战斗力的基础是每个个体的战斗力。只有每个个体员工都奋力向前,团队才有可能快速前进。那么如何提升每个个体的战斗力呢?这主要与两个要素有关,即个体能力和他使用能力的意愿,如果要用一个公式来表示,那就是“个体战斗力 = 个体能力 * 个体意愿”。
|
||||
|
||||
关于如何提升员工的个体能力,我们在上一篇文章中已经进行了探讨。现在,我们再来看一看如何提升员工的工作意愿和积极性,也就是很多管理者都头疼的员工激励问题。
|
||||
|
||||
员工激励是管理者的日常工作之一,为什么会让很多管理者头疼呢?他们大体上有如下几类说法:
|
||||
|
||||
“没有头绪,无从下手。员工激励这事,想起来就做做,忙起来就顾不上了。”
|
||||
|
||||
“员工没有工作热情,怎么激励也提不起积极性,他们依旧我行我素。”
|
||||
|
||||
“对员工激励效果最好的就是股权、晋升、调薪、奖金,我会向上级去争取,但是可能很难争取下来。”
|
||||
|
||||
“没法左右加薪和奖金,只能是给员工画饼了,但是工程师对此都很无感。”
|
||||
|
||||
还有很多说法,但是我们归结起来,不外乎是如下三个问题:
|
||||
|
||||
第一,激励认知不系统。不清楚激励都有哪些手段,以及如何使用,各种零散的说法让人无所适从。
|
||||
|
||||
第二,激励可用资源匮乏。实实在在的物质激励不受自己掌控,画大饼的精神激励,员工又不买账。
|
||||
|
||||
第三,激励达不到效果。虽然激励的动作都做到位了,但是并没有收到激发员工动力的效果,或者效果不够令人满意。
|
||||
|
||||
接下来,我们依次看看这些问题该如何应对。
|
||||
|
||||
第一个问题,关于对激励的系统认知。于此,我们比较熟知的就是马斯洛的需求层次模型了,这个模型可以指导我们从人的五个不同层次的需求来激发动力,不过操作起来还是有点不太清楚该怎么做。
|
||||
|
||||
|
||||
|
||||
马斯洛需求模型
|
||||
|
||||
所以,我更喜欢丹尼尔·平克的《驱动力 3.0》,他把驱动力的发展归纳为三个阶段:驱动力 1.0、2.0 和 3.0。
|
||||
|
||||
驱动力 1.0,是指驱动力主要来源于对生存和安全的渴望,需求层次处于“马斯洛需求模型”的最底层。这类驱动力在 200 年之前的大部分时间都处于主导地位,人们为了寻求生存下去的基本要素而努力。
|
||||
|
||||
当然,也并不是说现在就不能用了,这和社会经济发展状况有关。比如上一代人就有个响亮的口号叫“学会数理化,走遍天下都不怕!”怕什么?还不是怕找不到工作,吃不饱肚子!这其实就体现了当时人们对于生存的恐惧。
|
||||
|
||||
不过,随着中国经济发展至今,人们对这个层次的需求似乎已经默认能够保障,所以不再是关注重点,在企业员工激励中,也很少会用到。
|
||||
|
||||
驱动力 2.0,其基本哲学就是认为人们都是“寻求奖励、避免惩罚”的,所以采取的方案是“奖励好的行为、惩罚坏的行为”,也就是人们经常念叨的“胡萝卜加大棒”。这是近 200 年来工业时代被广泛认同的激励方式,也是当前大部分管理者最常用的激励手段。
|
||||
|
||||
几乎在每一次管理培训课上,我都会邀请我班上的同学整理出他们认为最有效的激励方式。不出意外,你会发现大家呈现出的结论,80% 以上都是奖金奖品、升职加薪、口头表扬、通报表彰、出国旅游、加班费等,与此对应的惩罚就是罚款、批评等。
|
||||
|
||||
我问他们,“效果怎么样?”一般收到的回答是,“效果还不错,但就是越用效果越差。”不得不说,这是很正常的。
|
||||
|
||||
为什么正常呢?
|
||||
|
||||
因为无论是奖励还是惩罚,这类驱动力最大的特点是来自外部刺激。人对外部刺激的应对机制是增强免疫力,这个道理用在害虫身上就是提升“抗药性”。所以无论是用惩罚来“威逼”,还是用奖励来“利诱”,用多了就没效果了。古人早就告诫我们“善用威者不轻怒,善用恩者不妄施”,也是这个道理。
|
||||
|
||||
你可能会说,“既然‘善用恩者不妄施’,我以后就少奖励员工吧?”那就又因噎废食了。我认为还有一个“不妄施”的做法,就是把每一个奖励的意图都明确化以加强感知。除非是过节,否则就不要“撒胡椒面”,去搞所谓“阳光普照”奖。
|
||||
|
||||
我就拿“表扬”这样的小奖励来举例,表扬一个员工,若遵循下面这三个原则和要素就会让你的表扬效果倍增:
|
||||
|
||||
具体。就是表扬的内容和原因要非常具体,让员工和团队都知道他是因为哪一两点得到了认可。比如“员工 A 非常主动及时地处理了一个线上故障”“员工 B 在带新员工方面成绩突出”等。这样做,大家就能够清晰地接收到你在倡导什么,而且还能有效防止对没有受到表扬的人造成负激励。如果你要是泛泛地说“A 很积极主动”“B 干得很不错”。其他人就会心里不爽:“我也很积极主动好吧,而且我项目干得也不错。”因此,表扬一定要具体。
|
||||
|
||||
公开。这个原则很简单,公开表扬有两大好处,一个是被表扬的同学受到了更大的激励;另外一个更大的好处是,你其实告诉了团队每个人,什么样的行为和价值观在你们团队是被认同和倡导的。因此,表扬要公开。
|
||||
|
||||
及时。所有的期待都有时效性,表扬及时,其实就是对员工的反馈要及时。一个不及时的表扬不但会让激励效果大打折扣,而且还会让团队成员很不理解,“这么点事,至于挖坟拿出来说吗!”
|
||||
|
||||
好了,关于驱动力 2.0 的核心理念,以及在工作中的广泛应用,相信你已经领会到了。
|
||||
|
||||
接下来我们聊聊驱动力 3.0。
|
||||
|
||||
驱动力 3.0,目前在中国企业里正在被越来越多地应用和开展,这和中国社会已经基本解决生存和温饱,人们开始追求幸福和意义是紧密相连的。如果说驱动力 2.0 的核心是外驱力,那么驱动力 3.0 的核心就在于自驱力。
|
||||
|
||||
你可能会说,“胡萝卜加大棒”都搞不定,靠员工自驱岂不是更不靠谱?但我不得不告诉你的一个事实是:用驱动力 3.0 的思路来激励员工,不是你愿不愿的问题,而是不可回避的选择。
|
||||
|
||||
第一个原因是,驱动力 2.0 的效果还是会持续变差。一方面是因为用滥了,没有新意;另外一方面,随着中国经济和文化发展,物质奖惩和别人的评价变得不如从前那么令人关注。很多 90 后职场人有着自己笃定的价值观。
|
||||
|
||||
第二个原因是,在这样一个信息时代,员工的创造力更能为公司创造价值,而创造力需要更多的自主和差异。这一点和工业时代的理念几乎是相反的。在工业时代,员工恪守规则、不出差错更能体现其价值,所以驱动力 2.0 的核心价值观是“顺从”;而驱动力 3.0 的核心价值观是“自主”。显然,我们无法选择让信息时代倒流到工业时代,所以,就只有努力去掌握如何使用驱动力 3.0 的方法去激励员工了。
|
||||
|
||||
既然,驱动力 3.0 主要是指自驱力,那么,究竟怎么激发员工的自驱力呢?丹尼尔·平克从三个方面给出了建议:
|
||||
|
||||
第一,提升员工工作的自主性。即,给员工一定程度的自主掌控感。
|
||||
|
||||
首先是工作时间和地点上的自由度。弹性工作时间,在互联网领域非常常见,这和互联网业务特别依赖员工创造力是分不开的。时至今天,还是有不少管理者抱怨员工总是迟到,如果他们管理的是知识型工作者,我一般会建议他们把焦点放在对结果的评价上,而不是把焦点放在员工的作息习惯上。应以结果为主线开展管理工作,而不是用控制来做管理,除非你们的行业性质更强调“服从”。
|
||||
|
||||
其次是工作内容上的自由度。员工可以在一定程度上选择自己的工作内容。Google 原来有个“20% 自由时间”的策略,即员工有 20% 的工作时间可自由支配,很受工程师们的热捧。所以,你在做季度规划的时候,也可以聊聊员工的意愿,看看能否兼顾个人兴趣和工作要求。
|
||||
|
||||
最后是工作方法上的自由度。也就是员工可以自主选择工作的实现方法,这在技术人的日常工作中是非常常见的。
|
||||
|
||||
总之,一定的自由度会让员工更有自主掌控感,从而起到激发的作用。
|
||||
|
||||
第二,提升员工专精度,让员工持续有成长。这里的“专精”强调的不是要设定目标去成为某个“专家”,而是强调“自主投入”的过程,为员工创造愿意自主投入的条件,因为只有自主投入才能带来专精。那么,都要创造哪些条件呢?
|
||||
|
||||
明确的工作目标。即,对员工的要求越清晰,他就越愿意投入努力。那么什么叫明确呢?以明确到他能着手执行为标准。
|
||||
|
||||
目标要略有挑战。即,对员工的要求要有一定挑战,但又不能太高。要求太高带给员工的是焦虑;要求太低带给员工的是无聊。如果你觉得难以理解,你回想自己玩过的游戏就明白了,太难了让人放弃,太容易了没意思,难度适中的时候你才最容易沉浸其中、物我两忘。
|
||||
|
||||
要能发挥其优势。每个人都愿意做自己擅长的事情,如果某项工作能发挥员工的独特优势,必定会给他带来投入的热情。你可能会说,哪有那么多可以发挥员工优势的工作?我想说,优势是有很多层次的。你可能满足不了某员工所期望的工作内容,但是还有行为模式和思维模式方面可以考虑,比如某些人特别爱和人沟通协调,那就让他用沟通讨论的方式去工作;如果有人特别善于独立思考和筹划,那就发挥他的思维优势;有的人行动特别迅速,那就让他去快速启动一项工作。总之,千万别简单认为发挥员工优势,就是鼓励员工“挑活”;优势是多层次的,所以让员工发挥优势这件事并不困难。
|
||||
|
||||
|
||||
|
||||
优势层次图
|
||||
|
||||
第三,给予员工意义和使命。现在越来越多的人开始关注工作背后的意义和价值。如果说驱动力 2.0 的核心在于“利益”最大化,那么驱动力 3.0 在不拒绝利益的同时,更强调的是工作价值的最大化,希望自己做出来的工作是有意义和价值的。
|
||||
|
||||
作为管理者你可以亲身感受得到,总会有一批人因为工作没有价值而离职。他们不是矫情,而是真的需要看到自己给公司和社会带来什么价值。所以,管理者的一项重要修炼,就是去梳理团队的使命和项目的意义。
|
||||
|
||||
在前面第 12 篇文章中探讨团队职能时,我提到过一定要为团队设定基本职责和使命,还记得文中那个测试经理的案例吗?当他明白了自己团队不仅仅是做测试的,更是整个公司产品和服务质量的保障者之后,激发了他持续的工作热情,这就是意义的价值。
|
||||
|
||||
但很多时候,管理者分配工作的方式是直接交代要做什么,并不会和员工去分享和探讨这项工作的价值,以及对团队和公司意味着什么,所以起不到激励效果。
|
||||
|
||||
综合上面所说的,我把驱动力发展的三个阶段整理如下,供你参考。在以后设计激励方案的时候,你可以关注一下,自己正在从哪个角度去激励员工。你也许会问,驱动力 3.0 时代,是不是就不需要外部的奖惩激励了呢?我的看法是:需要,虽然驱动力 2.0 的激励效果在不断打折扣,但是基本的奖惩还是要做到位,这是基线。
|
||||
|
||||
|
||||
|
||||
驱动力发展三阶段
|
||||
|
||||
关于激发员工的自驱力,说到底还是要顺应员工对于“工作幸福感”的追求。
|
||||
|
||||
驱动力 3.0 所强调的“自主投入”,只是工作幸福感的来源之一,那么除此之外还有其他哪些角度呢?“积极心理学之父”,美国心理学会主席马丁·塞利格曼在《持续的幸福》一书中,提供了一个“全面可持续幸福”(well-being)模型,即“PERMA”模型,为我们提升幸福感提供了一个可操作的框架。
|
||||
|
||||
|
||||
|
||||
积极心理学“全面可持续幸福”模型(PERMA)
|
||||
|
||||
从上图可以看出,正面情绪、人际关系、投入、成就、人生意义,是通往全面幸福的五根支柱。若你想要提升员工工作幸福感,也可以从这五个方向去开展工作。
|
||||
|
||||
第一,积极正向的情绪。你在营造什么样的团队氛围呢?团队里是轻松愉快、互帮互助的,还是抱怨指责、死气沉沉的?现在你知道了,积极正向的情绪,本身就是提升员工工作动力、增强员工留任意愿的重要手段,那你能为此做点什么呢?
|
||||
|
||||
第二,良好的人际关系。在团队工作中,你做了哪些工作来提升员工的归属感、融入感呢?你是否设计了一些活动和机制,让彼此之间更愿意互相支持?每个团队会因为管理者的风格选择自己的有效形式,但一个常见做法是,为每位新人指定导师,你做了吗?
|
||||
|
||||
第三,自主投入。你为员工自主投入提供条件了吗?如前面我们所提及的,为员工设定清晰的目标,给他们适当的挑战,并支持他们发挥自己的优势,可以帮你的员工提升自主投入的意愿,体验到“心流”带来的愉悦。
|
||||
|
||||
第四,取得成就。迎接挑战并取得成就,是大部分工程师非常享受的事情,但是这需要一个前提,就是对于“成就”的刻画和设计。很多管理者往往缺乏这个意识,尤其对于一些长线工作,或日常的琐碎工作,员工做下来觉得没有成就感,甚至是觉得浪费时间。所以,把长线项目里程碑化,把日常工作项目化,让员工走一步有一步的成果,会提升员工的成就感。
|
||||
|
||||
第五,意义和使命。你可能会说:“工作就是工作,哪里有那么多的意义和使命啊。就别说员工了,我自己都觉得很缥缈!”但是员工越来越追求工作背后的价值和意义这件事是不可忽略的。所以,作为管理者你需要有能力为员工梳理清楚这个问题。
|
||||
|
||||
这里我提供一个简单实用的方法,即尽量避免用“任务性”的语言,而多使用“成果性”的语言。比如你安排一项工作给员工,常见的说法是:“把项目 A 抓紧做一下吧,下周要发布。”这在员工看起来,他收到了一项任务。但换成“成果性”的说法是:“项目 A 会帮我们验证一个结论,决定我们是否在这个方向上持续投入,下周就要做出决策,所以,你看下周能否搞定?”显然,成果性的说法会让员工更清楚自己工作的价值,完成之后也会很有成就感。
|
||||
|
||||
此外,你会发现,定义你团队的使命和愿景,并和团队有效传达,为大家的工作赋予更高的意义和使命,不仅仅是规划要素、是驱动力来源,还是员工工作幸福感的五大支柱之一。
|
||||
|
||||
以上的五根支柱,既然能提升员工幸福感,那么就可以作为激励手段的框架供使用。
|
||||
|
||||
通过我们探讨的“驱动力 3.0”和“PERMA 模型”两个框架,你是否对激励这个话题有了一个全局和系统的认识呢?
|
||||
|
||||
如果认知问题得到了良好解决,那么员工激励常见的第二个和第三个问题也就迎刃而解了,我们一起来看看:
|
||||
|
||||
第二个问题,关于激励可用资源匮乏。实实在在的物质激励不受自己掌控,画大饼的精神激励员工又不买账。针对这个问题,如果你把“驱动力 3.0”和“PERMA 模型”两个激励框架结合起来使用,你会发现,现在你可用的激励手段已经非常丰富了。
|
||||
|
||||
你之前觉得匮乏,是因为你觉得只有“胡萝卜”和“大棒”可以用,而现在,你可以设计更为立体的激励体系了,而不是靠单一的激励来决定效果。
|
||||
|
||||
另外,说起“画大饼”,在我看来,“画饼”越来越成为管理者的必备技能,只不过不宜过大,饼太大了是没有激励效果的,要注意和员工有切实的联系。而且作为管理者,只有言行一致,保持承诺一致性,才能赢得团队的信任。
|
||||
|
||||
第三个问题,关于激励达不到效果。虽然激励的动作都做到位了,但是并没有收到激发员工动力的效果,或者效果不够满意。关于这个问题,我认为效果不明显最大的原因是你只是做了一套“激励动作”,这套“动作”可能是很多管理者前辈告诉你的,而不是你根据自己团队和员工的具体情况,结合激励框架定制化设计出来的。
|
||||
|
||||
实际上,每一个激励方案都需要去思考和设计,把外驱和内驱结合起来,把长期和短期结合起来,把业务推进和职业幸福集合起来,把个人工作和团队使命结合起来。别再把员工激励简单粗暴地甩锅给某句“名言”:“要么钱没给到,要么心受委屈了”,就好像你经常把技术问题甩锅给一个叫“bug”的东西一样。其实关键是,你打算做什么来改变这种状况呢?
|
||||
|
||||
这篇文章很长,最后归结起来,我希望传递这样几个理念:
|
||||
|
||||
第一,激励要立体。本文介绍了非常丰富的激励要素,你需要从单一的激励维度,升级为更加立体的激励体系,从而适应新职场环境的要求。
|
||||
|
||||
第二,激励在平时。你不能指望一些临时性刺激方案来做好激励,激励体系的搭建应在平时。当员工跟你提离职的时候,它就已经不再是一个激励问题了。
|
||||
|
||||
第三,激励要设计。由于每个人的业务特点不同、团队性质不同、管理风格不同、员工特征不同、问题挑战不同,所以不要迷信别人给你的激励建议,我更建议你充分考虑自己面临的实际情况,结合自己的特质和激励框架,来设计适用于自己的激励体系。
|
||||
|
||||
如果你接收到了,就为自己的团队设计一个激励方案吧!
|
||||
|
||||
|
||||
|
||||
|
99
专栏/技术管理实战36讲/19如何兼顾团队分工的稳定性和灵活性?.md
Normal file
99
专栏/技术管理实战36讲/19如何兼顾团队分工的稳定性和灵活性?.md
Normal file
@ -0,0 +1,99 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
19 如何兼顾团队分工的稳定性和灵活性?
|
||||
前面两篇文章,我们探讨了如何提升团队中每个个体的战斗力。那接下来的问题是,每个个体的战斗力都很强了,整个团队的战斗力就会很强大吗?凡是学过中学力学的同学都能脱口而出:“并不一定!”为什么呢?因为只有在大家努力方向一致的时候,团队的合力才会最大。
|
||||
|
||||
这个道理用马车模型来打比方会更加易懂。当拉车的各匹马用力方向不一致的时候,马车甚至都会一动不动,所以需要用一个“联动结构”来保证每匹马用力的方向是一致的。关于一群马的“联动结构”的设计,对应到团队管理中,就是如何做好人员安排和工作划分,以实现最高效的合作。我们把这个要素称为“分工”。
|
||||
|
||||
|
||||
|
||||
奔跑的马车
|
||||
|
||||
那么,各匹马拉车的方向一致了,并且每匹马都很用力,马车前行速度就最快了吗?显然,还有一个因素要考虑,那就是大家的步调和节奏是否一致,以及相互之间的配合是否默契。这对应到团队管理中,就是团队成员之间的协作水平和磨合度如何。我们把这个要素称为“协作”。
|
||||
|
||||
当团队个体间的分工和协作都很良好的时候,就可以将个体战斗力凝聚成强大的合力了。
|
||||
|
||||
关于如何提升员工协作水平和团队凝聚力的问题,我们会在下一篇文章中专门探讨。今天,我们就先来聊聊团队分工这个话题。
|
||||
|
||||
说起分工似乎大家都懂,不过,你是否真的清楚分工的目的呢?越是司空见惯、习以为常的东西,就越容易被忽略,所以很少有管理者深入地思考过这个问题,很多人第一反应的答案是为了追求更高的效率。
|
||||
|
||||
我想说的是,如果你要追求高效率的话,就应该减少分工,合作的人越少越好。我们时不时就会听说,某个团队裁掉一批人后业绩不降反增,为什么呢?抛开激励因素之外,还有一个原因是,如果协作不好的话,分工只会让效率变低。
|
||||
|
||||
那么,究竟为什么要分工?分工能带来什么收益呢?在我看起来,主要有如下三点:
|
||||
|
||||
第一,为了实现规模化,通俗点说,就是为了干大事。因为干大事需要很多人,当有很多人一起做事的时候,就得有一种方式来容纳这么多的人,这个容纳方式就是分工。所以,分工不是为了高效,而是为了能容纳更多的人来一起干更大、更复杂的事情,做简单的小事情,是不需要分工的。因此,要把整个社会的人都容纳进来,就需要分工为 360 行、3600 行甚至 36000 行。这样,整个社会才能做很宏伟的事业。
|
||||
|
||||
第二,为了实现协作。到底是因为分工了才需要协作,还是因为需要协作才必须分工呢?我认为是先有协作的需求,才有分工。换句话说,分工是手段,协作是目的,分工和协作是不能割裂开的。所以,如果你有一个分工方案对协作不利,就本末倒置了。
|
||||
|
||||
你可能会很惊讶:“还有分工会妨碍协作的吗?”有,而且还很多!因为很多管理者分工并不是为了协作,而是想当然地认为该分工,或者分工是为了让大家都有活干,或者是为了平衡团队成员利益关系,等等。我倒是不反对这些做法,但前提需要你很清楚分工是为了更好地协作,如果伤害了协作关系,那你就需要掂量掂量了。
|
||||
|
||||
第三,为了实现专精。时代发展需要全才,也需要专精人才,分工为这类人才的成长提供了很好的条件。他们可以把时间、精力和长期的练习都聚焦到某个点上,从而更容易实现对于某项技能或某个领域的精细掌控。而且,由于精细化分工只需要每个员工关心单一工作内容,所以管理者更容易从整体上用人之长、避人之短,让专业的人更专业。
|
||||
|
||||
所以,我们是出于规模化、协作和专精的目的来进行分工的,在做分工的时候不能忘记了这个初衷。
|
||||
|
||||
但是并不意味着分工就只能带来这几个效果,它其实还会引发很多延伸效果的。协作好的分工可以带来除“规模化、协作和专精”以外的其他好的结果,比如人力资源配置优化、人才获取成本降低、员工工作积极性提升、执行效率变高等。而协作不好的分工也会带来很多负面,比如视野狭窄、能力单一、恶性竞争、推诿扯皮,等等。
|
||||
|
||||
因此,并不能简单地认为分工一定是件好事。分工是不是好事取决于协作水平,协作水平又受限于管理者的管理水平。所以,管理者的工作意义重大。
|
||||
|
||||
上面,我们探讨了分工的目的。那么常见的分工形式有哪些呢?
|
||||
|
||||
从一个业务所涉及的各个角色的分工情况来看,互联网领域最常见的组织结构有两类,一类是矩阵式的,一类是 BU(BUSINESS UNIT)式的。
|
||||
|
||||
所谓矩阵式结构,可以这样简单地理解:员工按照角色被划分到不同的团队,每个团队都有自己的负责人。要做项目的时候,会有专门的项目经理来向各个角色的 leader 协调人力,然后把申请到的各个角色的人组织在一起去完成这个特定项目。一旦项目完成之后,人员将回归各自团队去迎接新的项目。
|
||||
|
||||
这样一来,人力资源是按照角色“横向”来组织的,而项目执行是按照任务“纵向”来推动的,就形成了一个纵横交错的矩阵式结构,所以叫矩阵式组织结构。这类组织架构的好处是各个角色团队的专业度都会很高,而且角色归属感比较强,资源调配灵活;但不足之处是项目执行起来较为低效,因为每次都要重新申请人力,而且每次的项目团队都需要重新磨合。
|
||||
|
||||
IBM、微软的很多部门都是类似的组织方式,他们也都有一个专门做项目管理的职位叫“项目经理”,和互联网公司既带人又做事的“项目经理”不同的是,他们主要聚焦于项目交付,而不对人的发展负责。
|
||||
|
||||
所谓 BU 式结构,直译过来就是“业务单元”式,也叫事业部制,是指做某项业务所有的人员和资源都统一调配,无论这个事业部是大是小,都角色齐全。这样做的好处是团队长期合作磨合充分,协作效率高,执行速度快;不足是各种角色自己都要有,资源冗余和浪费比较多。另外,由于某些角色不在业务主干上,团队规模比较小,能力要求也不高,所以其角色专业度很难提升。
|
||||
|
||||
上面这两种组织结构各有利弊,在很多互联网公司都在并行使用,甚至嵌套使用,并不冲突。不过,你还是要根据自己的业务特点、公司规模、发展阶段去选择合适的组织形式。
|
||||
|
||||
你可能会说,“我作为一个一线经理,团队规模小,角色单一,涉及不到上面说的组织结构的问题,对我来说团队分工主要是内部人员的工作安排问题,有什么建议吗?”
|
||||
|
||||
那接下来,我们就把视角从组织外拉近到组织内来看。
|
||||
|
||||
其实,对于一个具体的团队来说呢,工作安排分工是没有一定之规的,因为这和你的业务情况、人员状态、团队目标都紧密相关,而且很多事为了应急还会临时调整,所以怎么分派工作,还是以你的实际情况为准。
|
||||
|
||||
不过我可以分享几个常见的误区、问题和建议原则。
|
||||
|
||||
首先,最常见的一个分工误区,就是分工模糊。而且有些管理者为了能够让大家互相补位、主动承担、增强互助,还会刻意去模糊边界。朋友圈里也时不时就会有一篇文章倡导“去边界化”或者“边界模糊化”。我非常理解这种做法的初衷和期待。
|
||||
|
||||
但是我想说的是,任何不以分工清晰为前提的边界模糊化,结果都会事与愿违。为什么呢?因为只有明确的分工,才能让员工清楚和认同自己的本职职责,产生归属感,并愿意主动付出多做一些。所谓“多做一些”是什么含义呢?就是在清楚自己该做什么的基础之上,又多做了一些,这是所谓主动积极的体现。
|
||||
|
||||
如果没有职责边界,却又总是催促员工要积极主动,员工可能就会质疑:到底做了什么才叫积极主动呢?你可能就无法回答。作为 leader,此时你如果只是随便列举几个做法,是不能令人信服的。因此,我不是反对去边界化,我只是强调,在“边界模糊”之前,要加上“分工明确”这四个字。
|
||||
|
||||
接下来,我们来聊聊分工稳定性的问题。分工需要尽可能稳定,因为只有稳定的分工才能体现出分工的价值,比如对某项工作的专精、员工的归属感等,所以,分工能稳定的话,就最好稳定。
|
||||
|
||||
但是也有两个因素会让分工稳定不下来。一个因素是来自外部的业务调整,团队组织结构不得已随之而变,管理者就需要对团队成员进行工作再分工。此时就要遵循“尽可能稳定”的原则,因为变量越多,不确定性就越大。
|
||||
|
||||
除了这种被动调整之外,还有一个因素是作为管理者的你想主动调整分工。你调整的原因可能很多,但是其中需要有一个原因是你意识到了长期稳定的分工带来的局限和怠惰。因为分工能带来专精,同时也带来了割裂的视野,所以很多管理者会通过“轮岗”的方式来提升员工的能力和全局观。我认为这种主动求变的意识非常好,因为主动求变就意味着这种变化是在你的掌控之内。
|
||||
|
||||
最后,我们再来聊聊虚拟组织。虚拟组织又叫虚拟团队,是为了某一个特定的目的和工作内容把大家组织到一起的。有的时候是为了一项临时性工作,工作做完之后就解散了,叫临时性虚拟组织;而有的时候是为了一项长期的工作,会一直持续很久,就会变成一个长期存在的虚拟团队。
|
||||
|
||||
为什么要组建虚拟团队?虚拟团队有哪些好处呢?我觉得至少有如下三点:
|
||||
|
||||
高效执行。虚拟团队组建的初衷一般都是为了专人专事,聚焦目标,高效执行。所以虚拟团队比一般的联合项目组,在执行上要更高效。
|
||||
|
||||
资源配置。对于很多工作来说,专门组建一个团队不值得,但是又时不时需要立项新项目,虚拟团队就为这类需求提供了解决方案。大家可以因为做事走到一起,但不是一个独立预算的团队。
|
||||
|
||||
保持归属感。为了做一些紧急项目,管理者往往会随意抽调员工,这样的事情出现的多了,员工的归属感会减弱,边界感会消失。慢慢地员工就认为自己是在“打杂”了,因为他找不到自己的位置在哪里了。而虚拟团队本身就带有“借调”的味道,并不影响员工认定自己“本应”的位置在哪里,所以,不会影响员工的归属感。
|
||||
|
||||
你可能会说,“既然虚拟组织这么好,那我就多用这种方式吧!”好,接下来我就说说,使用虚拟团队这种方式需要注意的几个原则:
|
||||
|
||||
专人专事,不宜太多。虚拟组织往往是专人专事的,代表着足够高的重视和足够高的要求,所以对应也要有足够多的资源投入。但你不可能把所有的事情都列为重要的事情,也不可能所有的事情都专人专事。所以,“好钢用在刀刃上”,虚拟团队不宜太多。
|
||||
|
||||
认同员工价值。虚拟团队除了专人专事,还往往出现在跨团队的合作中。既然你同意你的员工加入这个虚拟组织,无论做出来的业绩是不是你最看重的,都要认可他的价值。常见的一个问题是,管理者常常以员工的产出对自己团队价值不大为理由压低员工绩效,这是典型的让员工背负管理者的决策后果,很不可取。
|
||||
|
||||
目标明确,职责冠名。每个虚拟组织建立起来都是为了特定的目标,所以你组建每个虚拟团队的目标要非常清晰,并且和团队每个人都要传达到位。为了进一步提升责任感和归属感,很多 leader 会把职责冠在团队名字上,我认为非常好。比如“100 天战队”“用户体验优化小分队”“架构迁移大队”等,很是生动形象。
|
||||
|
||||
当然,还有一些学习型虚拟组织,比如技术交流小组、项目负责人小组等,这些虚拟组织出于学习,不涉及工作分工,所以,不在我们今天讨论的范围内。
|
||||
|
||||
通过今天的文章,对于分工,你是否有了更深的理解?对于如何平衡团队分工的稳定性及灵活性,你是否有了更多的思路呢?欢迎你给我留言,我们继续交流。
|
||||
|
||||
|
||||
|
||||
|
85
专栏/技术管理实战36讲/20有什么方法可以有效提升团队凝聚力吗?.md
Normal file
85
专栏/技术管理实战36讲/20有什么方法可以有效提升团队凝聚力吗?.md
Normal file
@ -0,0 +1,85 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
20 有什么方法可以有效提升团队凝聚力吗?
|
||||
在上一篇文章中,我们共同探讨了团队分工的一些方法和要点。那么,为了达到团队成员间的良好合作,分工明确就足够了吗?显然,分工明确只是具备了合作的前提和基础,真正能够让大家良好互动并高效产出的,是日常工作中的协作。
|
||||
|
||||
如果说分工是一台电脑的硬件,决定着各个组件的拼接关系和基本性能,那么协作就是这台电脑的软件,是让这台电脑真正运转起来的关键。也就是说,是协作让团队里的各项工作开展起来的。这就是我们团建六要素中的第四个要素:协作。
|
||||
|
||||
那么,何为良好的协作呢?我们听到过很多相关的形容词:“紧密的”“顺畅的”“高效的”“默契的”……总之,所有能够用于个体之间良好互动的形容词,都可以用在这里。还有一位资深管理者很生动地描述说:“就是只要一句话,甚至是一个动作、一个眼神,对方就知道是什么意思。”显然,协作水平很高的团队,就好像一部良好运转的机器一样,既有分工,又彼此紧密连接,形成一个有机整体。
|
||||
|
||||
那么该如何不断提升团队的协作水平呢?主要是从两个角度来做工作:
|
||||
|
||||
第一个角度是建立协作机制,通过机制来约定协作的动作,以此来保证大家“动作协调”。关于机制怎么建,我们会在后面的第 27 篇文章“流程机制”中专门探讨,这属于“做事”的范畴,我们暂且不展开。
|
||||
|
||||
第二个视角是提升团队凝聚力,通过提升团队成员间的信任度、认同度和默契度来降低协作成本,提高协作效率。
|
||||
|
||||
团队凝聚力和协作水平是两个非常有意思的概念,他们含义不同,又紧密相关。团队凝聚力更侧重团队成员间的关系,体现他们的信任度和向心力如何;而协作水平则更关注做事过程中的互动情况。
|
||||
|
||||
你不难发现,一个非常有凝聚力的团队,对于良好的协作有着直接和关键的影响,而良好的协作反过来也会提升团队成员间的认同度和默契度,从而提升团队的凝聚力。他们互为因果、彼此促进。
|
||||
|
||||
所以,要想提升协作水平,“硬件”靠机制,而“软件”靠凝聚力。凝聚力即是团队协作的基础,又是团队协作的目标。强大的凝聚力,是战斗力强大的团队的重要特征之一。
|
||||
|
||||
那么,如何来提升团队凝聚力呢?
|
||||
|
||||
在我统计的 500 名左右的管理者中,有三大话题是他们最关心和认为最具挑战的,分别是前面探讨的员工激励,后续即将探讨的向上沟通,以及本文我们探讨的团队凝聚力的提升。可见,这是管理者普遍的痛点之一,我从如下四个角度给出可参考的方法。
|
||||
|
||||
第一个角度,设立共同愿景。
|
||||
|
||||
当我们想提升团队凝聚力的时候,总是希望大家“心往一处想,劲往一处使”,而我们常常忽略一点,就是大家首先得清楚把劲儿用到哪“一处”。这就要求团队首先要有一个使命和愿景,有一个共同的长远目标,供大家“往一处想”。
|
||||
|
||||
关于团队使命的意义和价值,我们在第 12 篇文章探讨团队“职能定位”的时候就已经提及,并介绍了设定团队使命的要点。而且,在第 13 篇文章探讨团队“目标设定”的时候也提出,清晰的目标可以提升团队的凝聚力。
|
||||
|
||||
如果团队有着自己的使命,又能得到团队成员的普遍认同,大家会更容易朝着一个方向共同努力,也更容易肩并肩地一起迎接挑战,即所谓的“志同道合”。它是如此重要,下面我简要描述一下其设立步骤:
|
||||
|
||||
明确你团队的职责、使命和工作目标。可参照前面的第 12 篇和第 13 篇,这里的工作目标是长远的共同目标。
|
||||
|
||||
管理者自己要笃信第 1 条的内容。如果不笃信,就返回步骤 1 继续提炼。
|
||||
|
||||
在各种合适的场合宣贯这一内容,比如季度会、总结会、沟通会、启动会,以及 1 对 1 沟通等,都要不失时机、不突兀地把使命和愿景同步给大家。
|
||||
|
||||
坚持不懈地做步骤 3。不要指望一蹴而就,开个会大家就都认同了的好事,现实中不会发生,只有时间长了、频次够了,才会内化,才会深深植入员工的内心。
|
||||
|
||||
第二个角度,提升员工归属。
|
||||
|
||||
如果说,设立共同的愿景,是为了让员工凝聚到共同的事业上的话,那么提升员工归属感,则是为了让员工凝聚到团队上,让员工从心里就认为自己是团队的一份子。那么,如何才能让员工有这种感觉呢?主要从以下三个层次来做:
|
||||
|
||||
要给他一个位置,给他一个“立足之地”,也就是要分给他一份职责也就是要分给他一份职责。职责并不总是意味着压力,也意味着归属,人的内心深处是渴望承担适当的责任的。只有当员工清楚自己能为团队做出什么贡献的时候,才会心安,才会感受到自己是团队的一份子。所以在团队分工上,要让员工清楚他肩负的职责对于团队的意义,让他觉得自己做的事有价值,这就是所谓的“事对”。
|
||||
|
||||
要营造良好的团队人际关系,让彼此间形成紧密的连接。团队成员间良好的关系,和团队凝聚力的提升是互为因果的,所以不要小看能促进员工间关系的一些小事,恰恰是这些小事,能够促使员工间的合作关系走上正向循环的轨道,员工会因为喜欢和团队的人相处而觉得有归属感。这就是所谓的“人对”。
|
||||
|
||||
明确亮出团队的文化价值观。团队的文化和价值观是否是员工认同和欣赏的,决定了他能否长期留在团队。价值观方面的冲突是很难调和的,如果员工从价值观层面就不认同团队,是很难让他找到归属感的。好在团队文化本身就是一个筛选器,最终留在团队发挥核心作用的都会是认同团队价值观的人,当然前提是团队先有明确的价值取向。关于如何打造团队的文化和价值观,我们将在后面的第 22 篇文章中专门探讨。因喜欢一个团队的文化和氛围而产生归属感,这就是所谓的“味对”。
|
||||
|
||||
如果一个团队能让员工觉得“事对”“人对”“味对”,那么,他的归属感应该是很强的。
|
||||
|
||||
第三个角度,加强相互了解。
|
||||
|
||||
作为管理者,我们总是习惯于对员工提要求,比如,希望员工能不能更包容些,相互之间能不能多一些体谅和理解,彼此之间能不能多一些信任,等等。作为管理者,我们总是期待“不劳而获”,认为员工之间天生就要互相包容、体谅、理解和信任。殊不知,所有这些并不会自然而然地发生,都要基于团队成员间不断深入地相互了解和认同。你为此做了什么呢?你有持续地做吗?
|
||||
|
||||
管理者经常会做一些团建活动,但是却很少对增进大家的了解和信任做必要的设计,回头活动效果不好,就归咎于活动不够吸引人、预算不充足等等。
|
||||
|
||||
而实际上,经过设计的活动,不但效果很好,而且还不需要什么经费。比如我曾经尝试给大家做过 1 个小时的“巅峰故事会”:在 1 个小时内,每个人都讲出他们曾经的巅峰体验,然后请队友给出积极反馈。1 个小时下来,产生了很多的化学反应,大家都说比之前更了解对方了,也更接纳对方了。
|
||||
|
||||
所以,这主要还是看你是否愿意为此花一点心思来稍微设计一下。无论如何,加深员工互相的了解,是提升信任和默契的良方。
|
||||
|
||||
第四个角度,共同面对挑战。
|
||||
|
||||
关于有哪些可以有效提升团队凝聚力的手段,在我的调研中,有不少管理者反馈,一起面对挑战的时候,特别能够让大家拧成一股绳,我也深以为然。
|
||||
|
||||
有一句经典台词就是这么说的:“今日谁与我共同浴血,他就是我的兄弟。”显然一起扛过枪的兄弟,感情是很铁的,毕竟是经历过不离不弃的并肩作战。虽然我们现在没有仗要打,但至少有如下两个方面的事情近似打仗:
|
||||
|
||||
跨团队的对抗性活动,比如趣味运动会、Dota 比赛等。
|
||||
|
||||
毋需去说教,而是让大家在“硝烟”和“炮火”中去建立深厚的感情,这就是所谓的“事上练”。
|
||||
|
||||
好了,关于提升团队凝聚力的四个方面的工作,我们可归结为如下:
|
||||
|
||||
|
||||
|
||||
对于如何提升你团队的凝聚力,你认为从哪个方面入手会最有成效呢?期待这张图能对你的工作会有所启发。
|
||||
|
||||
|
||||
|
||||
|
103
专栏/技术管理实战36讲/21如何物色和培养核心人才?.md
Normal file
103
专栏/技术管理实战36讲/21如何物色和培养核心人才?.md
Normal file
@ -0,0 +1,103 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
21 如何物色和培养核心人才?
|
||||
能够带着团队把一件事做好,只能算是一个好的项目经理(特指以项目交付为目标的 Project Manager)。如果能够带出一个良好的团队,持续不断地把一件又一件的事情做好,才算是一个好的团队管理者。所以,团队产出是否可持续,是考量管理者价值的一个很重要的维度,它体现了这个团队是否健康,是否有耐力和韧劲。其中,耐力让团队走得远,韧劲让团队走得稳。
|
||||
|
||||
在第 16 篇文章中我们提到,提升一个团队的耐力和韧劲,有两个要素:梯队培养和团队文化。一个团队的梯队,就好像一个团队的“骨架子”,这“骨架子”是否健康良好,决定了团队是否健壮。而团队文化就好像是团队的气质和调性,它会吸引“气味相投”的人持续加入,而把不符合团队气质的人筛选出去,越来越鲜明的团队价值观让大家紧密地聚拢在一起,从而让团队越来越“结实”,越来越“经得起折腾”,不断增强团队的耐力和韧劲。
|
||||
|
||||
团队文化的打造,我们下一篇文章会专门介绍,今天我们主要聊一聊梯队培养的问题。
|
||||
|
||||
我们通常所说的“梯队建设”,其实包含了“梯队规划”和“梯队培养”两部分内容,你可以认为规划和培养的关系,是“计划”和“实施”的关系,是“想”和“做”的关系。梯队规划的部分,我们在前面介绍“规划四要素”的时候已经做过介绍,所以今天我们把焦点就放在梯队如何培养上。
|
||||
|
||||
“梯队培养”实际上就是选拨一些人,并把他们培养成团队的核心骨干,也就是团队的“骨架子”。这其中包含了两个部分的工作:一个是选拨和物色培养对象,另外一个是培养这些人。
|
||||
|
||||
人才的选拔和物色,是个仁者见仁智者见智的话题。有“务实”派,认为“能者上”;有“务虚”派,认为“有德者居之”;有“现实”派,认为“能自己冒出来的才是人才”;有“理想”派,认为要“德才兼备,宁缺毋滥”。
|
||||
|
||||
在我看起来,作为管理者的你可以有自己的人才观,但是物色培养对象应该要满足以下两个原则:
|
||||
|
||||
第一,要保持人才选拔和团队建设的一致性。即,你对核心人才的选择,需要和你团队建设的理念保持一致,这主要体现在能力、协作和文化三个要素上。
|
||||
|
||||
能力。主要是确保其个体能力和业务特点相互匹配,能力潜质是可成长的。一般来说,技术团队的梯队,个体的专业能力肯定是要不错的,至少在业务特点方面要匹配。比如,对于功能交付的团队,其功能开发质量和效率是否突出;对于算法团队,其算法能力是否良好等。这是一个团队的能力基因。
|
||||
|
||||
协作。其协作的意识和能力,和你团队的要求和期待是否匹配。一般来说,团队的核心骨干都要有比较好的协作意识,才可以干更大的事情,才可以发挥一个骨干需要发挥的作用。尤其当你团队特别强调协作的时候,如果他在协作上有明显不足,那你就得考虑是否要把他作为培养对象了。
|
||||
|
||||
文化。其行为风格和价值观,和团队文化价值观是否匹配。比如,你团队如果倡导“积极主动”或“自驱”的团队文化,那么一个专业能力很强但是被动的人是否值得你培养?你团队如果提倡“强执行”的做事理念,那么在执行上有明显短板的人,你也就需要慎重去考虑。
|
||||
|
||||
所以,什么是好的高潜人才和培养对象,和你做团队建设应该是一脉相承的。应避免你一方面倡导和推崇某个理念,而在选人上又是另外一个理念。注意我这里强调的是一致性要求,而并没有说什么样的人一定是好的,因为“好”这个字充满了个人偏好,没有定数。
|
||||
|
||||
第二,和你相似的人才是人才,和你互补的人才是更宝贵的人才。如果说上一条原则我们强调了价值观层面的一致性,那么这条原则就是在强调行为风格和思维方式的多样性。
|
||||
|
||||
管理者作为成长发展方面的“成功人士”,多少都会有些“成功路径依赖”,也就是认为“类似自己这样的人才是好的”,所以很多管理者自然而然地会喜欢用和自己风格相近的人。事实上,风格相近的人协作效率的确会高,但是会缺乏更丰富的见地和视角。而在信息时代,多元才能带来更大的创造力,所以在价值观相近的情况下,行事风格和思维方式与自己不一样的人,更值得你关注。
|
||||
|
||||
比如,如果你是一个做事非常细致谨慎的管理者,不妨选拔一些行动特别迅速的人;如果你是个特别关注事的管理者,不妨选拔一下特别关注人的人……当然,这只是一个选择、一个视角,而不是说必须要这样选。
|
||||
|
||||
至于其他人才物色的原则,那就仁者见仁智者见智了,这里我就不展开探讨了。
|
||||
|
||||
接下来的问题是,人才物色出来了,要怎么培养呢?有三件事情很重要:
|
||||
|
||||
第一,对齐期待,达成共识。常用方式是 IDP,即个人发展计划。
|
||||
|
||||
关于 IDP 的制定,每个公司都有自己的模板,按要求炮制就好。我的习惯是把绩效计划和 IDP 合二为一:其前半部分是关于绩效的约定,比重在 80% 左右,换句话说,培养人才也是要以做出绩效为依托,而不只是为了培养而培养;后半部分是关于成长的约定,比重在 20% 左右,主要约定了未来的一个绩效周期内,个人需要特别聚焦的成长有哪些,并通过“把哪几件事情做到什么标准”来体现,也为之后的评估和反馈提供了一个参照。
|
||||
|
||||
在对齐期待的环节,有一个原则需要引起重视,就是不承诺原则。你在和培养对象共同制定培养计划的时候,最好秉承“不承诺原则”,意即,“我培养你,但是不承诺为你做职位设定和晋升”。很多管理者为了激发培养对象的成长动力,常用句式是,“如果你干得好,将会如何如何……”我的建议是,只明确培养的意向和计划就足够了,最好不要作出成长之外的承诺。
|
||||
|
||||
这主要有两个方面的原因:一是他能否成为团队核心骨干,或晋升某个岗位,是靠他自己的影响力来获取的,而不是靠你们的约定和承诺;二是为培养失败留下退路。如果你承诺了,未来却又兑现不了,那这个人才大概率就流失了。但如果你们聚焦于个人的成长而不是承诺,那么就不存在失败之说,即使没有培养成为你期待的骨干,也有各种方法继续激励和留用他。
|
||||
|
||||
当然,IDP 只是一个手段,只是为了对齐你和培养对象彼此的期待,让他清楚你关注和在乎的是什么,在这个事情上形成共识,从而形成良好的互动和有效的反馈。
|
||||
|
||||
第二,提供机会和发挥空间,做好授权。
|
||||
|
||||
做培养计划只是第一步,而能力和影响力都是在实战中积累起来的,这就需要给培养对象提供发挥空间,让他在“事上练”,所以就不可避免地要做工作授权。关于授权,我调研过的大部分管理者都有自己的心得,这里我开列出一个表格,供你参照和查漏补缺。
|
||||
|
||||
|
||||
|
||||
“工作授权三段法”
|
||||
|
||||
工作授权,并不只是用于人才培养,还可能是因为自己应接不暇时,迫不得已把一些工作授权给员工来做,这种授权以交付结果为核心目的,姑且叫做“被动授权”,不是今天的话题。今天我们探讨的是用于培养人才的“主动授权”,也就是图表中的“示例 2”。你可能会发现我用的是“示例”这个字眼,而且其中有很多带引号的描述,就表示这不是一个标准的做法,而只是按照左侧的“要点”举的例子,只是为了方便你理解这些“要点”的。
|
||||
|
||||
接下来,我对要点清单逐一做个说明:
|
||||
|
||||
审视初衷。主要是管理者审视自己想要在此次授权中收获什么,你是想把某件事做出来,还是想把人带出来,抑或是其他?你可能想说,“我都想要!”也不是不可以,但是总得有个先后主次。明确初衷,就是为了避免“什么都想要”的心理最终导致自己决策标准模糊。
|
||||
|
||||
明确期待。如果说“审视初衷”是为了让你明确想要什么,那么“明确期待”就是为了让培养对象清楚你对他的期待是什么,也就是你们就授权目标达成的共识。既然是目标,也就需要符合 SMART 原则。这一点是管理者普遍能够想到的,可能会有不同的表述,比如明确要求、明确口径等,都是一回事。
|
||||
|
||||
听其思路。这一点管理者很少能想到,大家往往想到的是在授权过程中如何把控风险。我建议,当你交代好授权任务之后,你可以首先听听他对这件工作的看法和思路。你从他的思路和方案中就大体可以判断出,他独立负责这项工作的靠谱程度如何,这不失为风险把控的良方。
|
||||
|
||||
重要约定。即,你需要对你特别关心的事情和他做一个约定,比如在什么情况下他需要告知你。这里我想强调的是,既然是授权,你最好不要动不动、时不时就去询问和干涉他的工作。在“向上沟通”的访谈中,很多人都非常反感和抵触“上级时不时就过来问进展”,因为在他们看来,这是上级的不信任。所以,关于怎么 check 进展,你们最好提前有个约定。
|
||||
|
||||
了解进展。大多管理者都能够想到这一点,就是在工作进展过程中要了解进度、评估风险,而不是任务交代完了就撒手不管了。
|
||||
|
||||
给予支持。在工作执行过程中,管理者需要给予必要的支持和帮助,这一点也是大部分管理者能够想到的。在人才培养的主动授权中,我推崇的方式是教练式的引导和启发,而不是直接告诉答案,因为经过他自己的思考,他才能更好地掌握工作技能。
|
||||
|
||||
评估结果。对于任何一次授权,针对授权对象的工作结果和表现给予有理有据的评价和及时的反馈,都是必要环节。有些管理者在工作完成之后认为事情就了结了,其实这样授权的效果便大打折扣,因为对人的培养和激励,都蕴含在反馈之中。
|
||||
|
||||
洞察优势。盘点在整个授权过程中,授权对象所表现出来的突出的优势有哪些,比如特别谨慎周密、特别有责任心、思路特别灵活、特别善于合作、善于沟通表达等等。在他的工作表现中,你会对他有更多的认识和了解,也会在以后的授权中有更好的匹配。
|
||||
|
||||
积极反馈。就是对于授权对象的工作,一定要给出一些“正向”的反馈,即,有哪些做的好的方面。主要目的是告诉他,哪些做法是你们推崇和提倡的,哪些是需要持续保持和增强的,同时也能起到激励的作用。
|
||||
|
||||
一条改进。就是要给出 1~2 条改进建议,也许你认为他需要改进的地方非常多,但是你需要明白,要想取得良好的改进效果,就得逐条改进,所以,不妨先提出 1~2 条建议,剩下的以后再说。
|
||||
|
||||
以上就是授权的 10 个要点,我把它们划分为事前、事中、事后三个阶段。从要点的分布你可以看出,授权的重点在于事前的安排和事后的反馈。因为既然是授权,事中最好不要干涉太多,只做约定好的 check 和支持就好。
|
||||
|
||||
第三,建立反馈机制。
|
||||
|
||||
在前面我们探讨授权要点清单的时候,已经提及了在一次授权工作中反馈的重要性和方法。现在,我再提几点外围的建议。
|
||||
|
||||
建立周期性沟通机制。即,和你的重点培养对象,建立周期性的沟通机制,让沟通常规化,而不是想到了就沟通一下,想不到就不沟通,这样会比较随意,沟通不系统也不深入。至于周期是多长,就和你的具体情况、具体需要有关,两周常常是个不错的间隔周期。
|
||||
|
||||
review IDP。IDP 做出来之后只是发挥了一部分价值,即双方明确了目标和期待;对于 IDP 执行情况的评估和反馈,才能体现 IDP 更大的价值。因为只有在反馈中,你们才能对齐对这件事情的看法和观点,这里不但蕴含着是非对错的价值观,还蕴含着指导和激励。
|
||||
|
||||
安排第二导师,给予支持和反馈。为了使培养对象得到更好的成长,也可以为他安排一个除你之外的“指导老师”,这个导师未必一定是团队内的,团队外的效果常常也不错。只要是你信任和认可的就好。
|
||||
|
||||
这样,你对于核心人才的多角度的反馈机制就建立起来了。
|
||||
|
||||
很多管理者托词工作太忙而没有时间带人,但如果你不把带人这件事作为你工作的“大石头”,你会发现,你只会越来越忙,而且,能做的事情也很难扩展。所以,团队核心人才的培养对于管理者来说,是一个非常重要的工作内容。
|
||||
|
||||
好了,在核心人才选拔和培养方面,你有遇到过哪些困惑吗?你又有哪些经验可以分享呢?欢迎给我留言。
|
||||
|
||||
|
||||
|
||||
|
111
专栏/技术管理实战36讲/22如何建设团队文化,营造团队氛围?.md
Normal file
111
专栏/技术管理实战36讲/22如何建设团队文化,营造团队氛围?.md
Normal file
@ -0,0 +1,111 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
22 如何建设团队文化,营造团队氛围?
|
||||
提到文化,很多人都会“如堕五里雾中”,模模糊糊地知道,又看不真切。用钱钟书的话说就是:“你不问我文化是什么的时候,我还知道文化是什么;你问我什么是文化,我反而不知道文化是什么了”,很生动地描述出我们对于文化的感受,它似乎无处不在,却又很难一下子说清楚。
|
||||
|
||||
既然,文化定义起来都很难,那么为什么还要把团队文化作为“团建六要素”之一呢?接下来,我说说我的理由。
|
||||
|
||||
虽然,对于团队文化本身,没有唯一确定的定义。但是,每个团队,都有一些约定俗成的工作方式和是非判断。在这个团队中,即便没有人告诉你什么是对的、什么是错的,你大体上也清楚什么该做、什么不该做。它虽然不像规章制度那么带有明确而强制性的约束力,却也能引导和规范团队成员的言行举止,我们把这种潜移默化的行为准则和工作作风称为团队文化。
|
||||
|
||||
如果还是觉得的有点“虚”的话,你可以问自己一个问题:你希望用什么词汇来形容你团队的气质和调性呢?或者,你最愿意让什么样的员工留在你的团队里呢?这大抵就是你团队的文化。由于团队文化里往往蕴含着团队最推崇的价值观,所有也会把团队最核心的文化,称作团队的文化价值观。
|
||||
|
||||
我们可以通过一些名企的企业文化和价值观,来进一步地理解这个概念。
|
||||
|
||||
Google 有一条众所周知的价值观叫做“不作恶”;
|
||||
|
||||
百度早期的核心价值观是“简单可依赖”;
|
||||
|
||||
阿里的核心价值观是“客户第一”“平凡人做平凡事”等;
|
||||
|
||||
腾讯的核心价值观是“正直、进取、合作、创新”。
|
||||
|
||||
你也许会说,这是一些大公司的企业级的文化价值观啊,我带的这十几个人、几十个人的团队也需要有吗?
|
||||
|
||||
答案是,不但需要,而且很重要。不信你去看看那些有凝聚力、有战斗力的团队,他们都是有鲜明的气质和调性的,比如有的是“强执行”文化,有的是“靠谱”文化,有的是“极客”文化,还有的是“温暖”文化……不一而同。
|
||||
|
||||
那么,鲜明的团队文化及价值观,究竟能给一个团队带来什么呢?
|
||||
|
||||
第一,效率。这是由文化的秩序性带来的效果。由于文化里包含着约定俗成的工作标准和决策依据,并且团队成员都对此持有共识,因此不必事事请示上级和彼此确认。比如,一个“强执行”的研发团队,每个人都知道依计划行事并坚决兑现承诺的重要性;一个强调“安全”的数据团队,每个人都会考虑在工作推进过程中的安全措施。统一的行为准则和协作上的默契,带来了工作效率的大幅度提升。
|
||||
|
||||
第二,空间。这是由文化的导向性带来的效果。由于文化里约定了团队的价值导向,也就意味着,在符合价值导向的前提下,员工可以自主选择自己的工作手段,甚至是工作内容。这为很多有主动性的员工提供了自主发挥的空间。在“员工激励”一文中我们提到,自主性能够提升员工的投入度,激发员工的自驱力。所以,明确的文化也是激励手段。
|
||||
|
||||
第三,归属。这是由文化的筛选性带来的效果。由于团队文化里蕴含着价值观,所以团队文化有“筛选器”的作用。认同该文化的人会不断加入进来,而不认同该文化的人也会逐渐淡出,久而久之,团队里都是对该文化认同度很高的员工。价值认同是一种高层次认同,一旦认同,便具有很好的稳定性和黏性,这种认同为大家带来了深深的团队归属感,共事的员工也更有凝聚力。在盖洛普的“优势理论”中有关于“完美团队”的描述,即,“价值观相同、能力互补的团队”,可见价值观对于团队的重要意义。
|
||||
|
||||
第四,耐力。这是由文化的延续性带来的效果。文化对于一个组织,是相对稳定的元素,它能够在新、老员工间传承,并不会因为个别人员的变动而明显变化,除非是团队负责人有调整,才会给团队带来明显影响。2013~2014 年,百度有很多工作多年的老员工离职,这和当时公司从“简单可依赖”的文化,转而倡导“狼性文化”不无关系。从这里也可以看得出,一个企业或一个团队的文化,对于其稳定性、健壮性及耐力的重要作用。用通俗的话说就是,一个拥有鲜明而稳定的价值观的团队,更扛得住“折腾”。
|
||||
|
||||
既然团队文化能够带来这么多收益,那么要怎么打造自己团队的文化呢?
|
||||
|
||||
打造团队文化的步骤非常简单,大体分为三步,我给每一步起了一个好记的名字,分别叫“命名它”“主张它”和“追求它”。但是,每一步都有很多误区,我们接下来详细聊一聊。
|
||||
|
||||
|
||||
|
||||
第一步,“命名它”。其实就是提炼你团队的文化,用合适的词句把它表述出来。看上去非常简单的事情,却有着最为普遍的两大误区。
|
||||
|
||||
第一个误区是“拿来主义”。有些高管看到“别人家的文化”非常好,而且公司做得也很成功,于是就希望直接拿过来作为自己的文化来沿用。但他忽略了一个基本事实就是,一个团队的文化价值观,主要来源于团队负责人或核心管理者。你是什么样的作风和价值观,你团队就会是什么样的,也就是说,你的团队文化和你喜欢什么样的文化关系不大,而和你是什么样的人关系很大。比如:
|
||||
|
||||
面对问题,如果你总是抱怨,那么和团队强调积极文化是不会成功的;
|
||||
|
||||
面对合作,如果你总是对抗,那么和团队强调紧密协作是不会成功的;
|
||||
|
||||
面对工作,如果你总是被动等待,那么和团队强调积极主动是不会成功的;
|
||||
|
||||
面对下属,如果你总是漠不关心,那么和团队强调温暖有爱也是不会成功的。
|
||||
|
||||
所以,你想打造什么样的团队文化,核心是从你身上的优秀品质中提炼,从而把你优秀的特质放大到整个团队。若你身上没有的特质,那就不适合作为团队的文化价值观去培育。
|
||||
|
||||
第二个误区是“越简练越好”。于是很多公司提出的文化价值观就是几个词,比如前面我们提到腾讯的文化价值观是“正直、进取、合作、创新”,这在我眼里就是个反面教材,因为你记不住,就算是记住了,也很快会忘掉,因为很难感知,也太没区分度了。
|
||||
|
||||
所以,文化价值观的描述方式应该是越生动越好,而不是越简练越好,因为目的是为了让大家记住且传播。当然,如果能既生动又简练就更好了。这里我举几个好的案例,供你参考:
|
||||
|
||||
Google 的“不作恶”,非常简洁而生动;
|
||||
|
||||
百度的“简单可依赖”,也非常容易记忆和传播;
|
||||
|
||||
滴滴有个部门,他们的文化是“首问责任制”,就是“第一个被问到的人,就是推进该问题解决的责任人”,他们解释过一次我就记住了。
|
||||
|
||||
那么现在,避开上面我提到的两个误区,从你自己认同的价值观和优秀特质中去提炼出生动易传播的文化,你可以做到了吗?
|
||||
|
||||
第二步,“主张它”。就是要把你提炼出来的团队文化,宣贯给整个团队成员,甚至还包括上级和合作的兄弟团队。这是很简单的事情,是吗?在一次管理培训课上我特意做了一个统计,结果是,全班 30 多位管理者,大约只有 6 位管理者有明确的文化描述,但是却没有一位和自己的团队全员做过明确的主张。换句话说,这事主要是他自己清楚。而这种状态下,前面我们提到的团队文化的各种收益,他都拿不到。
|
||||
|
||||
当然,主张团队文化,也并不是要你做“祥林嫂”,见着谁就跟谁讲,而是要有意识地在一些公开或私下场合,去把你的团队文化告诉对方。比如,在开季度会的时候,可以和全员来宣贯,并作出详细解释;在你和团队成员 1 对 1 沟通的时候,也可以适时强调;在跨团队沟通中,也可以看情形主张。
|
||||
|
||||
总之,这里的关键在于,你是否有这个意识,以及是否愿意花这份心思。
|
||||
|
||||
第三步,“追求它”。这也是最重要的一步。有些员工并不买管理者的账,也不买团队文化的账,认为那就是管理者“洗脑”用的,喊喊口号,没什么实际意义。
|
||||
|
||||
一般出现这种情形的原因有两个:要么是文化提炼的时候,不是从管理者自身提炼的,管理者不能以身作则,做不到言行一致;要么是没有把团队文化和管理工作结合起来,在员工眼里就是“光说不练”,没法让他们感受到遵照这种文化的益处。
|
||||
|
||||
对于第一个原因,我们在前面“命名它”中已经探讨过。对于第二个原因,管理者更容易出现的是误区是“想当然”。我遇到过以下这样的情况:
|
||||
|
||||
“我们要打造团队文化,我申请了两天的徒步拉练,上级一直不批。”
|
||||
|
||||
“做一场拓展吧,去锻炼一下队伍,打造一下文化氛围。”
|
||||
|
||||
“创业团队嘛,去趟沙漠,来磨练一下大家的意志。”
|
||||
|
||||
以上这些说法,如果没有在活动中把团队文化要素设计进去,活动下来效果肯定不会好。因为对于每项活动,每个人的视角和态度都是不同的,不设计、不强调、不引导,文化的共识是很难被捕捉到的。
|
||||
|
||||
而且,更为重要的是,文化的践行,更多的体现在管理工作中,而不是活动中。比如:
|
||||
|
||||
你在和员工约定绩效方案的时候,有没有体现团队文化和价值的内容?
|
||||
|
||||
你在评优和表彰员工的时候,有没有明确体现团队文化价值观?
|
||||
|
||||
你在选拔新人导师的时候,有没有和团队文化挂钩?
|
||||
|
||||
你在项目成功发布的时候,有没有总结团队文化?
|
||||
|
||||
你在辅导和教导员工的时候,是否有提及团队文化?
|
||||
|
||||
……
|
||||
|
||||
正是这些日常的管理工作,蕴含着你的团队文化,它其实一直都在。团队文化的打造,并不是要无中生有,而是要把它提炼出来,发挥更大的引导、规范和传承的价值。
|
||||
|
||||
至此,关于如何建设自己团队的文化,你是否心里有数了呢?
|
||||
|
||||
|
||||
|
||||
|
75
专栏/技术管理实战36讲/23如何和低绩效员工谈绩效?.md
Normal file
75
专栏/技术管理实战36讲/23如何和低绩效员工谈绩效?.md
Normal file
@ -0,0 +1,75 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
23 如何和低绩效员工谈绩效?
|
||||
如果你要问,哪些管理场景对于新经理来说是最挑战的呢?我想,和低绩效员工谈绩效这事儿,一定是榜上有名的。因为我曾经无数次地被问起,有没有和低绩效员工谈绩效的方法和技巧。既然如此,团队建设相关的第一个典型场景,我们就来聊聊这个话题。
|
||||
|
||||
你可能会困惑,关于绩效沟通的问题,不应该是管理沟通的内容吗?为什么会放在团队建设这个章节来讨论呢?这是因为绩效沟通的核心,其实并不在沟通上,相信读完这篇文章之后,你会赞同我的说法。
|
||||
|
||||
既然和低绩效员工沟通绩效,是众多管理者都觉得很头疼的事情,那么,为什么这个事情这么令人头疼呢?
|
||||
|
||||
首先就是自己的心理在作怪,因为在你看起来,你和低绩效员工的这次沟通,你不得不带给他一个“坏消息”,而没有人会很享受带给对方一个可能会令对方不悦的消息。这就是为什么很少有管理者会头疼跟高绩效员工谈绩效,因为他们认为高绩效是一个“好消息”,和员工怎么谈都问题不大。这是人之常情吗?其实只是因为你把“低绩效”和“坏消息”划上了等号,而事实上,划上等号就意味着你误会了绩效沟通的目的。
|
||||
|
||||
如果说传递一个“坏消息”就会让你很不情愿的话,那更加重你心理负担的是,这个“坏消息”是你造成的,是你把这个最差的绩效名额给了他。尤其是当你觉得这个员工表现还不错的时候,你更加认为是自己伤害了他,对不起他,而且还得担心他能否接受,会不会因此就情绪失控,甚至流失。没有人喜欢歉疚,而你却要带着歉疚和忧虑去沟通,当然令人头疼。
|
||||
|
||||
实际上,无论是不情愿沟通“坏消息”,还是内心有歉疚和忧虑的负担,都是因为把绩效沟通的焦点放在了绩效结果和对结果的传递上,而没有看到绩效沟通有更重要的意义和价值。
|
||||
|
||||
那么,良好的绩效沟通要达到哪些目的?收获哪些价值呢?
|
||||
|
||||
对齐。绩效沟通的过程,其实是很好的对齐双方观点的机会。你们可以互相同步自己的信息,听取对方对于这些事实的看法和判断,了解对方在乎的焦点在哪里,交换双方对于同一个结果的评价标准,等等。所以,一个有效的绩效沟通,会在事实信息、逻辑判断、双方意图、评价标准等多个层面上进行对标,从而达成共识。
|
||||
|
||||
辅导。绩效沟通的过程,不仅仅是告知员工绩效结果,更重要的是通过对过去工作的回顾,让员工有更多的思考和觉察。所以,绩效沟通同时也是一个辅导员工成长的过程,当然这个过程最好不是说教式的,而是教练式的。
|
||||
|
||||
激励。好的绩效沟通,即便对方是低绩效员工,也会通过沟通令他重燃斗志,对未来充满希望,从而达到激励的效果。
|
||||
|
||||
你可能会问,绩效沟通如果能达到这三个效果,那就太美妙了,具体要怎么来谈呢?接下来,我们分三个方面来探讨。
|
||||
|
||||
第一,首先需要明白的是,绩效沟通的核心并不在于谈,而在于绩效管理全过程的完整性。如果绩效计划的制定、确认、review 都没有做到位,只是靠最后的沟通来求取共识,那是无论如何都达不到良好效果的。所以,我们先整体来看下绩效管理都包含了哪些事儿。
|
||||
|
||||
绩效管理大体包含五个步骤的工作:
|
||||
|
||||
绩效计划或绩效评估方案的制定。即,你未来给员工打绩效的依据是什么。
|
||||
|
||||
和员工确认绩效计划。即,你和员工都要认同这个评估手段,所以很多公司的绩效计划都是要员工签字的。
|
||||
|
||||
归档并维护。可能会因为员工工作内容的重大调整,中期会有一些更新。
|
||||
|
||||
绩效评估。你需要对员工在本次绩效周期内的工作表现进行评估和打分。
|
||||
|
||||
绩效沟通。就绩效评估结果和员工进行沟通,达到对齐共识、辅导和激励的效果。
|
||||
|
||||
你不难发现,绩效沟通是绩效管理的最后一步。如果前期工作做不好,仅在沟通阶段下功夫,就算技巧再高超,花样再多,也是假把式,中看不中用,很难让员工真正信服。毕竟,员工并不傻,很多时候被迫接受了你的说法,主要是觉得徒劳无益而已。
|
||||
|
||||
由于通常绩效相关的工作都是由 HR 来推进,所以,很多管理者把绩效管理和绩效沟通当成是 HR 的“政治任务”来完成,有的时候还把低绩效的问题归结为是绩效制度的弊端,和员工沟通的时候,也以一副“全赖公司和 HR,我也没有办法”的无可奈何的姿态。而实际上,这种做法并不能收获前面我们提到的三个目的中的任何一个,这是为什么呢?
|
||||
|
||||
因为,绩效说到底主要是你和员工之间的事儿,它作为一种管理手段,是用来确保员工的产出和你的预期相匹配的,所以是你俩之间的一个“工作协议”,其他人更多的是第三方的角色。既然是协议,那么就是双方都要认同才有效,所以第 2 步的“双方确认绩效计划”是最关键的,这是绩效沟通的基本前提和依据。
|
||||
|
||||
这里要特别强调一下,你对员工的绩效做评价时,一定要有评价依据,这个依据最好就是一起制定的绩效计划。最忌讳的就是在沟通中管理者有太多的个人感受和主观臆断,这是没有说服力的。
|
||||
|
||||
你可能会说,这个评价依据很难拿捏啊!的确是不好拿捏。不过既然这个协议就是员工的个人工作目标,那么 SMART 原则同样适用,你可以根据自己的情况去梳理,围绕着“一个可以评估且双方认同的工作协议”这个初衷展开,具体到可评估的程度。
|
||||
|
||||
第二,在绩效沟通之前,先摆正自己的角色和姿态。
|
||||
|
||||
对于新管理者,你在绩效评估和沟通之前,先审视一下自己的角色:你是这个团队的管理者,是这个团队的负责人,你是有责任来评价团队每个员工的工作表现和业绩的。你是站在团队的视角来看待这个问题,而不是站在任何一个成员的对立面来特别针对他。即便他做的也还不错,但是你如果还是把低绩效的名额给了他,那么你一定是有自己的依据的,所以这个绩效也的确是他应得的,你并不欠他什么。你有管理者的职业素养,有管理者的工作视角,也有令人信服的评价依据,你做出来的就是最公平和最恰当的决策。所以,你需要考虑的事情是,如何和他达成共识,期待并支持他也可以像其他同事一样,变得更加出色。
|
||||
|
||||
所以,你的角色不仅仅是一个评判者和告知者,还更是一个辅导者和支持者。
|
||||
|
||||
第三,把绩效沟通当作是承上启下的新起点,而不是末日审判。
|
||||
|
||||
绩效沟通,诚然要对过去的工作表现和成绩做出有理有据的评价,并且在相互探讨中达成共识。对于低绩效员工来说,如何让这个沟通不那么令人沮丧和压抑呢?
|
||||
|
||||
“着眼未来”是个好的做法。即,过去虽然很努力,但是结果却不尽如人意,那么如何能够改变这个状况呢?“往者不可谏,来者犹可追”,你可以引导他多说一些自己对未来的打算,希望接下来做些什么,打算怎做,以及需要哪些支持和帮助。
|
||||
|
||||
当你和他一起探讨他的发展的时候,会让他觉得“坏消息”属于过去,而未来是有希望的、被信任和支持的。这对双方来说,都是一个更好的起点,不是吗?
|
||||
|
||||
因此,在双方对于基本事实都认同的情况下,尤其要避免抓住过去的问题不放,如果把焦点放在对失败的探讨上,会让他感受到末日审判般的沮丧,以及对于改变这种状况的绝望与无助。而用教练式的引导方式,一起做一场着眼未来的、面向长期发展的绩效沟通,就能收获到辅导和激励的效果。
|
||||
|
||||
当然,所有以上的探讨,都基于一个基本假设,就是这个低绩效员工你还希望继续留用。如果你都没有留用他的意愿了,那就不再是一个绩效沟通的问题,而是如何辞退员工的问题了。
|
||||
|
||||
对于和低绩效员工谈绩效,你还有哪些困惑呢?欢迎你给我留言。
|
||||
|
||||
|
||||
|
||||
|
143
专栏/技术管理实战36讲/24如何让团建活动不再“收效甚微”?.md
Normal file
143
专栏/技术管理实战36讲/24如何让团建活动不再“收效甚微”?.md
Normal file
@ -0,0 +1,143 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
24 如何让团建活动不再“收效甚微”?
|
||||
某天晚上,在技术管理群里,一位有着多年管理经验的技术总监问:“大家有什么好的团建活动推荐吗?之前的团建活动都收效甚微!”
|
||||
|
||||
然后,热心的群友开始七嘴八舌地出主意:
|
||||
|
||||
“你多少预算啊?多少人?玩多长时间?”
|
||||
|
||||
“我们上周刚去了趟沙漠徒步穿越,效果挺好的,你可以考虑。”
|
||||
|
||||
“密室逃脱,特别有意思,大家玩得很开心。”
|
||||
|
||||
“建议野外生存,能快速拉近团队成员间的距离。”
|
||||
|
||||
“喝酒吃肉啊,喝酒特别能增进感情。”
|
||||
|
||||
“可以一起去钓鱼……”
|
||||
|
||||
“可以租个别墅玩桌游……”
|
||||
|
||||
我漫不经心地看着各种点子在屏幕上蹦现出来,大家越说越津津有味、兴趣盎然。直到一个人很不和谐地问了一句:“你希望通过团建达到什么目的呢?”看到这句话,我一下子来了精神,预感到这个话题终于要切入正题了,因为他触及到了“收效甚微”的病根。
|
||||
|
||||
虽说安排团建活动是管理者日常管理工作中很常见的一部分,但却很少有管理者敢说自己是团建活动的行家里手。我曾经做过几次统计,发现其中认为自己在这方面很擅长的管理者还不到 10%,剩下的 90% 都认为自己做的团建活动效果一般,甚至是“没什么效果”。
|
||||
|
||||
这到底是哪里出了问题呢?经过深入访谈,并结合我之前的带人经验,我发现很多人掉入了三个误区。
|
||||
|
||||
第一个误区,就是认为团建活动是万能的。
|
||||
|
||||
不少管理者总是有意无意地认为,团建活动是“包治百病”的良药,所以对团建活动寄予了太多的期待,但最后的结果是要么期待模糊,要么期待过高。
|
||||
|
||||
你不妨问问自己,也采访一下身边的管理者,一般会在什么情况下安排团建活动呢?你可能会收集到如下反馈:
|
||||
|
||||
在高强度、高压力的工作告一段落的时候;
|
||||
|
||||
在重大挑战之前给员工打气的时候;
|
||||
|
||||
在取得了重大工作成果的时候;
|
||||
|
||||
在公司庆典或者春节、圣诞等节庆日的时候;
|
||||
|
||||
在刚刚组建团队或者团队调整的时候;
|
||||
|
||||
在整个团队工作积极性不高的时候;
|
||||
|
||||
认为团队凝聚力不好或者彼此间合作不顺畅的时候;
|
||||
|
||||
希望打造团队文化的时候;
|
||||
|
||||
觉得很长时间没有做团建活动了,需要做一次的时候;
|
||||
|
||||
“新人”入职的时候;
|
||||
|
||||
“老人”离职的时候;
|
||||
|
||||
……
|
||||
|
||||
你会发现,团建的名目举不胜举,活动内容也是五花八门,相当丰富多彩。可是你是否审视过,这些活动能给你带来了什么效果呢?它们是否满足了你做这件事的初衷呢?很多管理者被问到这个问题时都会陷入沉思,因为平时很少思考这个问题。
|
||||
|
||||
盘点管理者安排团建活动的出发点,大体是如下三类:
|
||||
|
||||
以团队需要为初衷。比如提高员工积极性、提升团队凝聚力、打造团队文化、提升斗志、提升团队韧劲等。
|
||||
|
||||
以员工需要为初衷。常见的是调节放松,一段高强度工作之后,缓解员工的精神压力和紧张情绪。
|
||||
|
||||
以个人需要为初衷。比如,认为团建只是一项管理任务,需要时不时执行一次;或者只是单纯出于个人需要。
|
||||
|
||||
归结起来就是:为了团队、为了员工或为了自己,这三种活动定位。虽然我们习惯上把各种各样的活动都统称为 TB(team building),但是我更倾向于认为,只有把团队建设作为初衷的活动才叫做团建活动,而不是所有的活动都属于团建活动。
|
||||
|
||||
初衷不清晰在团建活动中有两个表现:期待模糊和期待过高。
|
||||
|
||||
期待模糊是指没有厘清这次团建活动要达成的效果,甚至还把团队诉求、员工诉求和个人诉求揉在一起。
|
||||
|
||||
比如,常常有管理者说:“大家最近很辛苦,这个项目完成后我们去郊区租个别墅玩。”我就想问了,你“租个别墅玩”,是为了什么呢?如果是为了做团建,让员工彼此之间有更好的认同度和默契,那么这个时机和方式是不是合适的呢?毕竟辛苦之后,你的员工们也许并不想再做一个团建。
|
||||
|
||||
而如果你是为了让员工调节和放松,这种方式就更加说不过去,毕竟休息方式是因人而异的。所谓休息方式,也就是一个人精力恢复的手段,有的是和别人聊聊天,有的是逛街逛商场,有的是玩网络游戏,而有的则是窝在沙发里发呆……你如果真的是想让你的员工们放松,就需要给他们自由度,让他们自主选择放松方式,而不是自作主张统一安排,那样员工只是“被休息”而已。
|
||||
|
||||
所以你看,作为管理者初衷不清晰,会给团队带来多么大的痛苦。
|
||||
|
||||
期待过高是初衷不清晰的另一个表现,即,希望通过一次或几次团建就能打造出有凝聚力、有战斗力的团队,这种想法是很魔幻的。如果你还记得我前面介绍过的“团队建设六要素”,就不难发现,团建活动能影响到的要素,也就是其中的 1.5 个:这 1 个是指“协作默契”,0.5 个是指“团队文化”。
|
||||
|
||||
为什么对团队文化的影响是 0.5 个呢?因为如果活动没有经过特别设计,是起不到“理解和认同团队文化”的作用的,最多就是增强一些团队归属感。
|
||||
|
||||
那对其他要素就没有作用了吗?显然,团建活动基本上不会影响能力、分工和梯队。事实上,一次活动如果影响到了这三个要素,倒也是件很可怕的事情。比如你去参加了一次活动,回来发现分工变了,你的心情可想而知吧:)
|
||||
|
||||
最后一个疑问是,为什么对激励也是没有效果的呢?一般来说,活动即便有刺激积极性的作用,也是非常短效的,收益并不明显。即便有时看似有收益,也是由于默契度和归属感两个要素的间接作用。
|
||||
|
||||
所以,团建活动直接影响的要素,仅仅是前面我提到的员工间的协作默契和团队上的团队文化。而你却希望通过团建解决各种各样的团建问题,满足各种各样的团建期待,你说是不是有点魔幻呢:)
|
||||
|
||||
|
||||
|
||||
团队建设六要素
|
||||
|
||||
你可能会说,能取得这两个方面的效果也不错啊。事实上,即便这两个方面的效果,很多团建活动也拿不到。如果你认为活动随便做做就能收获到不错的效果,那就说明,我们需要聊聊第二个误区了。
|
||||
|
||||
第二个误区,就是认为团建活动理所应当就有效果。
|
||||
|
||||
实际上,没有什么好的成果是理所应当的。如果不经过设计,一次团建活动下来,甚至连员工间的默契和团队文化建设这 1.5 个要素的效果都达不到。
|
||||
|
||||
比如,如果你想让员工间尽快熟悉、增进彼此认同,而按照员工的兴趣,选用的方案是去 KTV 唱歌,或者去钓鱼馆钓鱼,这个效果就很难达成,因为这些活动的关键环节都不在于彼此交流和互动。你也许会说,吃饭喝酒容易拉近距离,而事实上,饭桌上的交流都很浅层,并不能深入了解;加上饭桌上话题很发散,不欢而散也是常有的事,这样效果就是负向的。
|
||||
|
||||
再比如,如果你团队的文化是“强执行”,但是你对整个活动中的迟到、随性的行为却没有任何反应,也没有设计什么活动环节来体现“强执行”这个理念的话,那么这个活动对于你团队文化的建设是没有任何效果的。这就是我前面提到的,团建活动只对 0.5 个该要素起作用。
|
||||
|
||||
所以,很多时候团建活动“收效甚微”,就是由于缺乏设计导致的。正如一位 HR 朋友所说的,“管理者们只是看到了活动内容,却看不到背后各个环节都是精心设计过的。”一旦效果不好,管理者们常见的说法,要么是活动内容不好玩,要么是经费预算太少。
|
||||
|
||||
其实这两个要素都不关键,主要还是看活动有没有经过设计。比如,像“烛光夜话”“裸心聊”“巅峰故事会”这类活动,基本上不需要经费,也并不算多“好玩”,但是经过设计之后,对于增进员工间了解和信任却非常有效。
|
||||
|
||||
所以,我想说,缺乏设计,才是活动效果不好的主因。
|
||||
|
||||
当然,作为管理者,你可能在活动设计上并不专业,思路也不见得很新颖,所以可以和别人合作来完成。但是确保活动方案和你的初衷匹配这一点,你是不可回避的。
|
||||
|
||||
第三个误区,团建活动是部门助理、HR 或行政的事情,管理者配合就好。我想说,相比前面两个误区,这个才是最大的误区。
|
||||
|
||||
长期以来,在团建活动这件事上,很多管理者都是在配合部门助理、HR 或行政的同事工作,他们干的最多的是协助组织,然后对活动品头论足。
|
||||
|
||||
如果你恰好看到了这篇文章,今后请务必以主人翁的姿态来看待团建活动。原因有如下:
|
||||
|
||||
从收益看。团建活动的主体和对象,即团队,是你的,所以活动能够在团建方面给你带来哪些帮助,是你要考虑的,这就是所谓的团建的初衷和目的。部门助理、HR 和行政只是在帮你达成这个效果而已。如果你不操心这事,又怎么期待效果恰好如你预期呢?
|
||||
|
||||
从成本看。你付出了最大的成本,如果你不考虑收益,你就亏大了。千万别觉得团建活动只是花了你团队一些预算,其实更大的成本是整个团队要把这么多时间投入进来,这个时间和人力成本是很昂贵的。而且员工还投入了自己的意愿和耐性,你不能默认每个员工都是愿意参加活动的,也许很多人只是因为“团队活动不好推托”才参加的。所以,你能给大家带来什么效果才对得起这个成本呢?
|
||||
|
||||
你看,无论从期待的收益,还是投入的成本,你都是最在乎的那个人。因此,从现在开始,做团队活动的主人,与部门助理、HR 和行政同事,一起去筹划,而不是完全假手于人。
|
||||
|
||||
至此,我们介绍了导致团建活动“收效甚微”的三个误区,那么如何才能做出“收效显著”的团建活动呢?
|
||||
|
||||
答案是,避开那三个误区,然后遵循下面的四个步骤。由于它们同时也是四个问题,所以我称之为“团建活动四问法”:
|
||||
|
||||
第一问,关乎初衷:你是想做团建活动,还是调节放松,或是其他?
|
||||
|
||||
第二问,关乎角色:是你想做团建活动,还是只想配合一下助理、HR 或行政的工作?
|
||||
|
||||
第三问,关乎目标:你想达成团建的什么效果?默契还是文化?
|
||||
|
||||
第四问,关乎手段:活动方案和你的目标匹配吗?
|
||||
|
||||
通过问自己这四个问题,你的团队活动将不会再“收效甚微”,你要不要试试看呢?
|
||||
|
||||
|
||||
|
||||
|
103
专栏/技术管理实战36讲/25多任务并行该如何应对?.md
Normal file
103
专栏/技术管理实战36讲/25多任务并行该如何应对?.md
Normal file
@ -0,0 +1,103 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
25 多任务并行该如何应对?
|
||||
管理工作的三部曲——管理规划、团队建设和任务管理,到现在我们已经探讨完了管理规划和团队建设,从本文开始,我们进入任务管理的章节,也就是我们口头说的“做事”。
|
||||
|
||||
如果说我们研究管理规划,是为了把事儿做对,我们研究团队建设,是为了理顺做事儿的主体,那么,我们研究任务管理,就是为了把事情做出来,产出实实在在的业绩和成果。作为结果导向的管理者,这才是管理工作的落脚点。同时,也是验证管理规划是否合理、团队建设是否有效的最重要的标准和依据。
|
||||
|
||||
因此,“做事”是非常重要的管理内容。
|
||||
|
||||
既然这个事情这么重要,那我们是不是要花很多篇幅来探讨呢?不是的,我们从整个专栏的目录也可以看出,“任务管理”的比重并不高。这是为什么呢?因为这部分内容在大多技术管理者看起来都不是问题。
|
||||
|
||||
我在各种规模的公司都做过调研,所有的统计结果都显示,相对于其他管理话题,任务管理是技术管理者们最拿手的一项,不只是他们自己这么认为,他们的上级也是如此评价的。我想,这可能和工程师出身有关,工程师有一种确定性思维, “靠谱”是好的工程师天生的品质,凡是明确答应过的事情,往往都会如数兑现。
|
||||
|
||||
仔细回忆一下你遇到的执行问题,你也会发现,几乎大部分执行问题的主要症结不在执行本身,而是在角色认知、管理沟通、管理规划和团队建设上,因此,我们在“任务管理”这个主题上,也主要是探讨一些要点。
|
||||
|
||||
对于很多团队来说,大部分工作都是以“项目”形式存在的,因此,任务管理大体上又是项目管理,只是为了涵盖非项目的那些工作,我才把“做事”叫做任务管理。
|
||||
|
||||
话说回来,“做事”这个话题依然很大,我们要如何探讨呢?既然做事是一个过程,那么我们就分成“事前”“事中”和“事后”三段来探讨。
|
||||
|
||||
在做事之前,我们需要回答的问题是:要做哪些事?先做哪件,后做哪件?也就是分清楚轻重缓急,也叫优先级梳理。
|
||||
|
||||
在做事过程中,我们要确保事情的进展按照计划推进,尽在掌握之中,也就是有效地推进执行。
|
||||
|
||||
在做事之后,我们要复盘做事的整个过程,并从过去的经验之中抽取一些流程机制,以便以后在类似的场景下也可以做得更好、更顺畅。
|
||||
|
||||
因此,我们把事前的轻重缓急、事中的有效执行和事后的流程机制,称为任务管理三要素。这也是接下来三篇文章的三个主题。今天,我们就首先看看第一个要素,关于轻重缓急的梳理。
|
||||
|
||||
|
||||
|
||||
“做事”:任务管理三要素
|
||||
|
||||
虽然大部分技术管理者都不认为自己在任务管理方面是短板,但是仍然有一些问题困扰着大家,比如,“多任务并行该如何应对”,就是其中最突出的一个,特别是刚刚走上管理岗位不久的新经理尤其如此。为什么大家会头疼这个问题呢?因为大家面临的问题常常是人手不够,时间不多,但是要完成的工作却还在一件一件挤进来,这可怎么办呢?
|
||||
|
||||
实际上,对于每个团队来说,当下能做的工作是有限的,增加并发并不会让大家的产出更高效,所以,多任务并行问题归根结底还是优先级问题,即,你要优先保证哪项工作的顺利进行。
|
||||
|
||||
排项目优先级对于管理者来说是必备技能了,每月、每周甚至每天都在训练,相信你也对于“重要紧急四象限”耳熟能详了。我其实挺好奇,这个“四象限”对于盘点各项工作的优先级是否好用呢?
|
||||
|
||||
|
||||
|
||||
重要紧急四象限
|
||||
|
||||
我了解到的情况是,大家都很清楚“重要紧急的工作要排在最前面”“重要的工作要像大石头一样做长远安排”“紧急的工作要立即着手”“不重要不紧急的工作直接丢弃”等应对策略。可是令大家最困惑的是,到底怎么判断一项工作重要不重要,紧急不紧急呢?这个前置步骤才是最难以判断的,我举两个例子:
|
||||
|
||||
老板刚刚口头交代的临时任务,这到底是紧急重要的、紧急不重要的,还是重要不紧急的呢?这个场景常常被倾向于认为是紧急重要的情况,必须如此吗?
|
||||
|
||||
锻炼身体、学习培训常常被倾向于认为是重要不紧急的事情,情况真的如此吗?
|
||||
|
||||
对于上面的这两个场景,不同的人、不同的上级、不同的任务和不同的情况下,可能会被归入不同的象限,这并没有一个可供遵循的一定之规。那么当我们面对这样的问题时,该如何判断其是否重要紧急呢?
|
||||
|
||||
我采取的策略是问自己这两个问题:
|
||||
|
||||
如果做,收益是否很大?收益越大,这个事情就越重要。
|
||||
|
||||
如果不做,损失是否很大?损失越大,这个事情就越紧急。
|
||||
|
||||
你可能会有疑问,不做的损失越大,不也意味着很重要吗?为什么只强调紧急呢?我想说的是,如果想简化问题,就需要结合我们的实际工作场景。在实际的工作中,我们经常做的并不是梳理轻重缓急四象限,更常见的情形是,我们要把日常的工作分为两种情况:一种是计划内的,也就是按照我们的规划进行的;另外一种是计划外的,即突发的情况和任务。
|
||||
|
||||
我们的应对策略其实非常简单:
|
||||
|
||||
对于计划内的工作,我们更关注它在一个规划周期内的价值和收益有多大。我们会把价值足够大的任务安排进来,并持续地往前推进。
|
||||
|
||||
对于计划外的工作,由于是一种突发情况,是否要中断既有安排来高优先级跟进呢?中断既有安排一定是会影响正常推进的收益的,所以我们要做的决定是,是否要立刻跟进?如果不立刻跟进,带来的损失有多大?我们是否愿意并能够承担?如果不能,那就立即跟进。如果可以不立即跟进,那就转化为一个可以安排到“计划内”的工作,并参考第 1 条的策略就可以了。
|
||||
|
||||
总结起来,对于任何工作任务,决策的步骤就两步:
|
||||
|
||||
对于“计划内工作”,看收益是否足够大。收益越大就越重要,也就越需要给予相匹配的优先级、资源和关注度;收益相对不大,就放入“To do list”,作为待办任务处理。
|
||||
|
||||
对于“计划外的工作”,看损失是否足够大。损失够大,就按照紧急任务安排,以止损为核心目的;如果损失可控,就放入“计划内工作”列表。
|
||||
|
||||
这样是不是就容易操作了呢?
|
||||
|
||||
于是,我们可以改进一下“紧急重要四象限”,让它更加方便实操。既然我们可以通过看收益来判断重要性,通过看损失来判断紧急性,那么这个四象限我们就可以调整如下。
|
||||
|
||||
|
||||
|
||||
轻重缓急四象限(果见版)
|
||||
|
||||
关于任务优先级的安排,除了决策的步骤和方法,还有几个重要的原则,这里我特别交代一下,方便我们对齐认知。
|
||||
|
||||
第一,目标是需要一以贯之的。前面我们提到,通过看收益来判断一个任务是否重要,那么你参照什么来衡量收益呢?答案是目标。我们规划的目标里蕴含着我们一段时期内最重要的诉求和期待,也是衡量一项工作收益大小的坐标轴。
|
||||
|
||||
于是你会发现,目标的设定和评估贯穿着整个管理工作的全过程,目标越明确,在关键时刻我们的方向感就越强;反之,我们就会瞻前顾后,反复掂量却不得要领。所以,好的决断力,往往基于明确的诉求和目标。
|
||||
|
||||
第二,任务安排是弹性的。很常见的一个情况是,我们在做任务安排的时候,往往不自觉地会在心里做一个设定,即,这个项目做成某个样子才叫完成,所以需要预算这么多时间。而实际上,对于一个任务来说,其进度、质量和效果这三个要素是可以此消彼长的,所以在拆解任务的时候,对进度的预期不同,对质量的要求不同,对效果的期待不同,都会导致时间预算和优先级的变化。
|
||||
|
||||
所以,不能用固化的视角看待一个任务,每一个任务其实都是可以弹性安排的,不一定是你需要的 4 周,也不见得是上级希望的两周,根据进度、质量、效果的不同期待,你可以给出很多种排期方案。这体现一个管理者的经验是否丰富。
|
||||
|
||||
第三,沟通是不可或缺的。虽然排优先级主要是管理者来做,但是这并不意味着排好优先级之后就大功告成了。只有和所有相关的人员充分沟通了之后,才算是调整完毕,尤其是和自己的上级,一定要和他沟通新的工作安排方案。告诉他,你优先保证了什么,从而可能会影响什么。
|
||||
|
||||
一个有意思的情况是,上级更倾向于告诉你,他们想要什么;而不会主动告诉你,他们愿意用什么来交换。这不是他们“唯利是图”,也不是他们“只让马拉车不让马吃草”,而是因为评估影响并给出应对方案是你的工作,这是你最清楚且拿手的,而上级判断不出对你既有安排的影响到底多大。
|
||||
|
||||
所以,很多上级管理者跟我说,他们默认是需要沟通的,而不是默认不沟通,最怕大家最后给他们一些“surprise”。
|
||||
|
||||
此外,很多上级倾向于告诉你,每件工作都是重要的,都是要正常推进的。但这其实只是美好的愿望,你心里要有数。如果所有的工作都重要,那就意味着没有重要的工作,所以,你要清楚上级最核心的期待是什么,这就需要看你们长期合作磨合出的默契了。
|
||||
|
||||
好了,关于“做事”之前,我们如何安排任务的轻重缓急,我们就先探讨到这里。这篇文章,我们主要探讨了做事所包含的三个要素,以及在做优先级梳理时,可以遵循的步骤和原则。如果这恰好是你擅长的管理内容,欢迎你留言和大家分享你的经验和技巧。
|
||||
|
||||
|
||||
|
||||
|
105
专栏/技术管理实战36讲/26如何确保项目的有效执行?.md
Normal file
105
专栏/技术管理实战36讲/26如何确保项目的有效执行?.md
Normal file
@ -0,0 +1,105 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
26 如何确保项目的有效执行?
|
||||
在上一篇文章,我们探讨了如何梳理任务优先级,解决了“做什么”的问题。本文我们来看看如何把任务列表中的这些事儿都落实到地上,也就是“怎么做”的问题,即,如何确保执行过程可控、执行结果符合预期?
|
||||
|
||||
关于如何确保项目的有效执行,我们有两个探讨的角度。
|
||||
|
||||
第一个角度是充分条件视角,即,列出有效执行的所有要点,大家照着做就可以把项目执行好。估计这是很多新经理都希望的一个方案,但是,这基本是实现不了的。就别说是适用很多公司各个场景了,即便是总结出一套适用于一个公司多类项目的方案,也很难做到。所以,我们还是从另外一个角度来看项目执行的问题。
|
||||
|
||||
第二个角度是必要条件视角,即,我们探讨出一些要点,在项目执行中,只要有一个要点没有做到,项目就很难得到有效的实施。我们把这些要点整理出来,为我们的项目执行提供有价值的参考。
|
||||
|
||||
那么,都有哪些要点呢?换句话说,有哪几件事做不好,就必然会引发项目执行过程的不可控呢?结合我过去的项目管理经历和调研访谈来看,我发现有四大类问题最为集中。
|
||||
|
||||
第一大类,不知你是否遇到过如下的情况呢:
|
||||
|
||||
虽然你很清楚做某项目的初衷,但是并没有去设定可以衡量的目标。比如某次技术重构、某个模块性能优化等。也就是说,虽然你知道自己想要什么,但是不知道出于什么原因,你没有设定一个清晰可衡量的目标,而目标不够清晰的话,必然会引发时间预算、人力预算,以及优先级决策的模糊。
|
||||
|
||||
虽然在你眼中目标很清晰,比如“到年底某模块单机性能达到 500qps”,但是负责项目实施的员工并不知道该从哪里下手去执行。
|
||||
|
||||
在你看起来,两周能搞定的事情,员工却花了 3 周时间。诚然,完成质量的确很高,可是和质量比起来,你更希望在 2 周内发布。
|
||||
|
||||
项目交付时间提前到这个周末了,员工没有完成,可他为什么还一副很无辜的样子呢?
|
||||
|
||||
诸如此类的状况层出不穷。它们的共同特点在哪里呢?显然,它们都是有目标的,但是这个目标出现了三个情况:
|
||||
|
||||
目标不够明确具体,至少没有具体到执行人员可以执行的程度。
|
||||
|
||||
上、下级对目标的理解看似一致,实则有偏差,尤其是对进度、质量和效果的拿捏上。
|
||||
|
||||
归结起来,这三种情况都导致了目标不清晰的后果。当目标不清晰的时候,必然会引起员工在紧急程度、质量水平和效果取舍上的偏差,最后也就引发了执行上的偏离预期。你也可以回忆一下那些执行良好的项目,你应该不难发现,它们都有一个共同而又必要的条件:清晰的目标,只不过在实际执行过程中,每个人对“清晰”的理解会有所不同。
|
||||
|
||||
第二大类,请你回想一下在执行上令你不够满意的那些项目。然后问自己如下三个问题:
|
||||
|
||||
这个项目涉及到的各个相关团队,是否都有一个明确的负责人呢?
|
||||
|
||||
这个负责人和所有项目组成员,是否都清楚各方面的负责人呢?
|
||||
|
||||
这个项目是否有唯一的总负责人,以及总负责人是否有效呢?
|
||||
|
||||
这些看上去非常普通的问题,却是很多项目执行障碍的一大源头。其中有两个模糊的地方,让“责任人”这个简单的问题变得失控。
|
||||
|
||||
第一个地方是:各负责人对于“负责”的理解常常是不一致的。很多负责开发的工程师,他们认为的“负责”就是承担自己份内的开发工作,而项目某一角色的负责人是指对该项目中所有涉及项目执行和协调的问题都要负责。
|
||||
|
||||
第二个地方是:总负责人无效。即,虽然有名义上的总负责人,但是总负责人顾不过来也好、自己不认同也好,都会在项目执行过程中“缺位”。比如,各个角色的负责人,都会把他们的共同上级作为默认的总负责人;还有些创业公司干脆是创始人号称要自己带项目,但是这些人实际上又没这个时间和精力,在其位不能谋其政,所以导致的后果就是项目总出问题,然后就怪这个怪那个……
|
||||
|
||||
对于这个问题,我有个经过验证的方案可供参考。即,把上级作为“客户”来看待,并另寻总负责人和这个“客户”来对接需求。而这个总负责人,是从项目的各个角色的团队负责人中产生,来总体负责和协调该项目。如果各个角色之间有长期稳定的合作关系,比如某 APP 的迭代团队,就可以把各个角色的负责人组织起来,组成一个项目管理的虚拟组织,大家轮流来做总负责人。这样既解决了项目总负责人缺失的问题,还培养出多个更高级的项目管理人才。并且假以时日,整个团队甚至整个公司的项目交付水平,都会有明显的提升。
|
||||
|
||||
这归结起来,第二类问题是集中在大家认为最简单、最容易,但又最容易忽视的项目总负责人的“缺位”上。
|
||||
|
||||
第三大类,常见的说法有:
|
||||
|
||||
“如果 A 也像 B 那么积极主动,这个项目就不会出问题了,所以 A,你能不能更主动一些呢?”
|
||||
|
||||
“我们明明约好了有问题及时通报,为啥总有些人不通报呢!”
|
||||
|
||||
“我们各种各样的流程都有,很完整也很系统,但是大家就是不按照流程办事……”
|
||||
|
||||
你能看出上面这些说法反映了一个什么问题吗?
|
||||
|
||||
由于我们见识过某些优秀人员的优秀表现,所以我们就过于迷信人的主动性和职业水平,等出现了问题的时候,就总觉得是“人不行”。事实上,团队成员的能力水平都是正态分布的。另外,如果真的是“人不行”,那么人从“不行”到“行”也会是一个缓慢的过程,而此时此刻你就得做事,那你打算怎么办呢?这就要靠流程和机制了。
|
||||
|
||||
于是很多管理者就制定了全套的流程让团队遵循,但由于学习和执行成本很高,员工遵循起来非常痛苦,因此就干脆让流程机制去“睡大觉”。这也是很多团队的真实情况,他们有很多流程机制、规章制度的页面,但是还是做不好项目。
|
||||
|
||||
归结起来,这类问题主要体现为:
|
||||
|
||||
关于这个问题,我们会在下一篇文章中专门探讨,此时我们先不展开。只要了解到,这是项目执行问题的一个关注维度即可。
|
||||
|
||||
第四大类,常见的说法有:
|
||||
|
||||
“我通知了啊,为啥他们就是不听呢?”
|
||||
|
||||
“对方有问题不主动找我沟通,关我什么事!”
|
||||
|
||||
“我不知道啊!什么时候变更的?”
|
||||
|
||||
“不是说好了周五交付的吗,他们没有如期交付啊!”
|
||||
|
||||
类似的说法还有很多很多。相信你一眼就可以看出,这类情况就是“信息不对称”,大家在一些事情上没有达成共识,由此产生了协作上的偏差和误会。原因可能是对信息本身的理解就不一致,也可能是没有有效传递和同步,总之在沟通这个问题上有诸多的不顺畅,归结起来就是:
|
||||
|
||||
无论是哪种情况,导致的后果就是沟通没有到位。关于管理沟通的问题,是我们下一个篇章的主题,到时候我们也会做更详细的探讨。这里,我们先了解到,沟通不畅,是项目执行不到位的主要原因之一。
|
||||
|
||||
至此,我们就了解了项目执行过程中最常见的四类问题。
|
||||
|
||||
当然,关于项目得不到有效执行,也许还有许许多多的其他问题,就好像“不幸的生活各有各的不幸”一样,项目执行不好也各有各的原因。上面我们阐述的,只是最常见的四类问题。如果你的项目没有这四类问题,不见得一定执行良好,但是如果出现了这四类问题中的某一类,执行上一定会有问题。
|
||||
|
||||
所以,我把避免这四类问题的钥匙归结为“有效执行四要素”,即目标清晰、责任明确、机制健全和沟通到位,以方便我们梳理和诊断执行问题。
|
||||
|
||||
|
||||
|
||||
有效执行四要素
|
||||
|
||||
为了提升可操作性,我把这四个要素扩展为 12 个问题,如果你对某个项目的执行不够满意,又想了解到底是哪里出了问题的时候,就可以参照这个“问题清单”检查一下。相信很快你就可以找到问题所在,从而对症下药。
|
||||
|
||||
|
||||
|
||||
任务执行检查清单
|
||||
|
||||
项目或任务的管理和有效执行,是很多技术管理者的拿手好戏,本文可以算是抛砖引玉。你是否愿意分享你的心得和方法呢?欢迎你留言和大家分享。
|
||||
|
||||
|
||||
|
||||
|
81
专栏/技术管理实战36讲/27如何让流程机制得到有效的执行?.md
Normal file
81
专栏/技术管理实战36讲/27如何让流程机制得到有效的执行?.md
Normal file
@ -0,0 +1,81 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
27 如何让流程机制得到有效的执行?
|
||||
有一天,在“技术管理交流群”中,一位管理者抛出来一个问题请求支援,他说:“目前碰到一个问题,困扰我一段时间了。之前自己负责开发的时候,数据基本没问题。做管理之后,数据开发就分给别人做了。由于做管理沟通协调的工作占了我大量时间,团队成员的项目质量也没很好地把控,导致这次上线后出现问题较多。本来想着用人不疑,于是就大胆放权,结果出现了这么多问题。如果我自己亲自做是可以保证质量的,但时间又不够用,大家帮忙想想办法!”
|
||||
|
||||
如果当时你也在这个群里,你会怎么回复他呢?
|
||||
|
||||
要想有效地支持到他,我们首先得弄清楚问题的核心是什么。那么,这到底是个什么问题呢?人家已经交代得比较清楚了:数据开发这个工作,他没时间做,别人又靠不住,怎么办?显然,这是一个来自工作授权的挑战。
|
||||
|
||||
对于工作授权,在前面的第 21 篇文章中我们提到过,授权分为主动授权和被动授权。显然,对于这位管理者来说,他想做的是一次被动授权,即,自己忙不过来了,必须得有人来替他完成数据开发这项工作。他第一想要的是项目结果,只是他自己没有意识到这一点,把培养人的诉求也糅合进来了,比如他说“本来想着用人不疑,于是就大胆放权……”就显示出这种诉求的模糊。如果确定是要拿项目结果,就需要做出确保结果的安排,那被授权者的感受就不是第一位了。
|
||||
|
||||
能够兼顾做事和培养人,那自然是很美好的。但如果两者不能兼顾的时候,就需要非常清楚我们优先保证的是什么了。
|
||||
|
||||
当然,我并非是抓住这位管理者在授权方面的一点瑕疵不放,因为这并不是解决问题的关键。即便他非常清晰地意识到这就是一次被动授权,为了让别人把数据开发这项工作搞定,该怎么做呢?作为群友,我们是要给出建设性意见的。
|
||||
|
||||
我们说,要想让员工分担我们手头上的工作,要么靠梯队,要么靠机制。
|
||||
|
||||
所谓靠梯队,就是团队里有胜任度非常好的人,可以帮我们搞定这件事,并且这个人已经是这方面可靠的梯队人才。显然,我们案例中的管理者在数据开发上的梯队是靠不住的,那么就只能是靠机制了。
|
||||
|
||||
所谓靠机制,就是设计一套方案,来专门应对某个场景出现的问题,这套方案可以指导和“搀扶着”员工做好这类工作。你可能会说,带着员工一起做,不是会产生更好的效果吗?你说的有道理,但是这样做的最核心的目的达不到,即,要减轻管理者的负担和精力开销。
|
||||
|
||||
那么,机制要怎么建呢?
|
||||
|
||||
你可以先看看我们的对话。我是这样回复他的:“你这个问题并不难解决,因为你具备一个关键条件,就是你有成功经验。因为你亲自做这件事,是没有问题的,所以你要做的,要么就是把你的经验和能力迁移给员工,要么就是把你的经验和能力提炼出一套机制,让他们遵循这套机制来做就可以。作为管理者,如果你想抽出时间干别的,梯队和机制的建设会把你解放出来。”
|
||||
|
||||
“那么,我接下来梳理一下我的经验,形成文档。”他回答道。
|
||||
|
||||
“形不形成文档不是关键,很多文档整理出来也发挥不出作用。关键问题是,你觉得你做到了哪几点,让你可以保证项目质量?即,如果让你检查员工的工作,你检查哪几个点?”
|
||||
|
||||
“你提到的关键检查点的确很重要。我现在检查的时候,都是看到什么就问什么,觉得需要的话就去员工电脑上看一眼,这样可能会造成遗漏。”他想了想,继续说:“至于我为什么能保证质量,我觉得可能有三个点我做得比较好:第一,我特别关注数据指标的定义;第二,我会把数据计算逻辑和需求方进行确认;第三,我在交付项目前,会先做数据校验。”
|
||||
|
||||
“非常好,那么在你看起来,如果你的员工在这三个环节也都不出问题,你觉得他交付的项目质量能否得到保障?”我继续问道。
|
||||
|
||||
“八九不离十,不会出大的偏差。”
|
||||
|
||||
“那么如果你只是检查这三个关键点,你的时间和精力开销是否可以接受?”
|
||||
|
||||
“可以接受。”
|
||||
|
||||
“那么,这就是一套关于数据开发这件事的授权机制,你可以和员工商量一下怎么配合执行。”我总结道。
|
||||
|
||||
说到这里,我们就演示完成了一个授权机制的建立过程。在这个过程中,到底涉及到哪些步骤呢?归结起来,大体上是五步:
|
||||
|
||||
首先要明确该机制要解决什么场景下的什么问题,即明确目标。机制的一大特点,就是场景化特性非常明显,因为它们都是为了应对好特定场景下的问题而产生的。比如服务报警响应机制、公关事件应对机制、新人入职培养机制、项目沟通机制等等,你会发现前面的定语都是场景化的。对于我们前面的案例来说,就是为了应对“梯队靠不住,自己又没时间时,数据开发项目如何推进”这个场景。所以,你建立一个机制时,首先要描述清楚场景是什么。
|
||||
|
||||
提炼应对该场景的关键点。从你和其他经验丰富的人身上提炼出应对该场景的关键环节,因此当有成功经验时,这些关键点的提炼会容易得多。这里,我并没有说要去整理一个流程文档,因为和一个步骤完整的文档相比,关键点的提炼更为重要,这会让执行成本降低,也更有可操作性。这就是为什么在前面的案例中,我要问“你觉得你做了哪几点,让你可以保证项目质量?”而没有说:“你可以把你的经验整理成操作文档让员工照做。”
|
||||
|
||||
明确由谁来确保机制的执行,即谁在什么时候检查什么关键点。每个流程和机制的执行情况如何,谁来检查和确认呢?如果少了这个监督者,流程和机制的有效性就得不到保证。所以,每个机制,都要设立监督者或检查者。显然在前面的案例中,这位管理者本人就是那个检查者,也只有他自己才可以胜任。
|
||||
|
||||
确认操作成本。即,确认该机制对于执行者来说是可操作的。你建立机制是为了简化工作,最好能够做到“自动驾驶”,如果建立的机制反而给执行者带来更大的操作成本,那你就得反思这个机制建立的必要性。所以在前面的案例中我才会问:“你的时间和精力开销是否可以接受?”
|
||||
|
||||
沟通,并和其他执行人取得共识。由于机制的制定者和执行者常常不是同一个人,所以,该机制是否有效,以及能否实施,需要和其他执行人沟通,并达成一致。这就是我在前面的案例中最后所交代的“和员工商量一下怎么配合执行”。
|
||||
|
||||
通过这五个步骤,相信你也会制定出应对各种场景的机制。不过,随着日积月累,你会发现机制和流程越来越多,它们慢慢变得不再那么好用,最后甚至长篇累牍地躺在一些页面上“睡大觉”。那如何才能让这些流程机制得到有效的执行呢?
|
||||
|
||||
我认为,要想让机制具有可执行性,建立机制时还要遵循如下的四个原则:
|
||||
|
||||
可操作,即简单原则。也就是说,机制要以最小的学习成本和操作成本为原则,这是最首要的原则。如果建立的机制不具备可操作性,那么你自我感觉再完美,能应对的问题再多,最后也要被抛弃掉的。因为不具备操作性的机制是没有意义的。
|
||||
|
||||
只打关节点,即关键原则。建立一套机制,不必要对所有的细节进行完整的描述,没有人喜欢看长篇大论的文字,你只要告诉大家,在哪几个最关键的节点,做什么样的动作即可,而且这样的关键点也不能太多,以不超过 5 个为宜。这样做可以大大降低执行成本,提升机制的可操作性。
|
||||
|
||||
明确到人,即问责原则。在各个关键点由谁来跟进呢?这个问题要有明确的约定,不能完全靠人的自觉性。比如,你建立一个发红包的机制,若你只是说一句“迟到的发红包”,那你会发现,经常有人迟到了也不发红包;但如果你指定了一个监督人,由他去监督执行,那这个红包机制的运作就没有问题了。这就是所谓的问责原则。
|
||||
|
||||
从 case 中来,到 case 中去,即实用原则。千万不要为了建机制而建机制,每一个机制都要有实用价值。由于机制都是有场景化特性的,当场景发生了变化,机制也要随着升级,而对于机制的重新审视和学习都意味着额外的开销,所以,每个机制的维护都是有成本的。如果没有随着场景更新升级,那这些机制也就成了没有意义的机制,时间长了就变成大家常遇到的情况:什么机制都有,但是大家不执行,或执行效果不好,反而成了管理的累赘和负担。
|
||||
|
||||
如果我们在建机制的时候能够遵循上面四个原则,就可以大大提升机制的可执行性了。
|
||||
|
||||
在文章的最后,我想再分享两个关于机制的观点。
|
||||
|
||||
机制不是越多越好,而是越少越好。这个观点和前面提到的关于机制的简单原则、实用原则一脉相承。你要明白一个道理:机制的建立并不会解决问题,对机制的执行才能解决问题,而机制的建立、执行和后期维护都是需要成本的,所以,千万不要贪多,在风险可控的前提下,机制能不建就不建,能少则少。
|
||||
|
||||
关于到底是人靠谱还是机制靠谱。很多管理者都认为,事情都是人做的,人如果足够靠谱,机制就没什么用了。对此,我的看法是,人的靠谱度的方差比机制大,即,人靠谱的时候比机制靠谱,人不靠谱的时候会比机制更加不靠谱。即便是最靠谱的员工,也会由于身体状态、精神状态、情绪状态以及外部干扰变得偶尔不靠谱,而机制的意义就在于,当人不靠谱时,事情也不至于变得很差。所以,机制是为了保证做事的“下限”的。同时,机制有很好的迁移性和传承性,不会随着某个人的缺位而产生大的影响。因此,必要的机制是不可或缺的。
|
||||
|
||||
好了,关于如何让流程机制得到有效的执行,我们就先探讨到这里。逐步健全的梯队加上良性运作的机制,可以让管理者越来越体验到“自动驾驶”的感觉,你有此期待吗?
|
||||
|
||||
|
||||
|
||||
|
99
专栏/技术管理实战36讲/28管理沟通那些事儿.md
Normal file
99
专栏/技术管理实战36讲/28管理沟通那些事儿.md
Normal file
@ -0,0 +1,99 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
28 管理沟通那些事儿
|
||||
截至目前,我们已经探讨了“管理三明治”五部分内容中的前四部分:角色认知、管理规划、团队建设和任务管理。接下来,我们进入第五个部分的探讨,也就是无处不在的管理沟通。
|
||||
|
||||
如果说角色认知是管理工作的前提,就像空气一样弥漫在管理者所有的言行举止之中的话,那么管理沟通就恰似管理工作的载体,它就像水一样承载着所有管理工作的正常开展,离开了沟通,所有的工作都将搁浅而无法前行。它是如此重要,以至于我们要花 7 篇文章来探讨。
|
||||
|
||||
今天是第一篇,我们先一起来看看,技术管理者在管理沟通中可以遵循的框架。
|
||||
|
||||
|
||||
|
||||
“管理三明治”(果见)
|
||||
|
||||
管理沟通是个大话题,也是很多公司培训课的重头戏,相信你也参加过不少 HR 组织的管理沟通课,你感觉怎么样?在管理沟通问题上是否胸有丘壑、游刃有余了呢?
|
||||
|
||||
我预计答案并不乐观,因为我对超过 500 位技术管理者进行过统计,列出 12 个最常见的管理话题请他们选出自己认为最有挑战的选项,霸占前三位的总是这样三个话题:向上沟通、员工激励和团队凝聚力提升,其中向上沟通几乎是每次调研的榜首。而且,紧随这前三甲之后的,往往就是向下沟通。如果把向上沟通和向下沟通加起来,在不包括横向沟通的情况下,就已经一骑绝尘地把其他话题抛在身后了,可见管理沟通是技术管理者心中当之无愧的“最具挑战管理主题 NO.1”。
|
||||
|
||||
那么,为什么技术管理者们认为管理沟通是如此地挑战?尤其对于向上沟通会如此地头疼呢?
|
||||
|
||||
好,我先请你看看下面的四项工作有什么特点:
|
||||
|
||||
技术开发工作:使用电脑、学习语言、设计算法、开发功能、遵循规范……
|
||||
|
||||
项目管理工作:明确需求、制定计划、把控流程、推动执行、通报进展……
|
||||
|
||||
和下级合作:分配任务、跟进进展、辅导帮助、激发动力、评价结果……
|
||||
|
||||
和上级合作:领取任务、领会意图、提供建议、申请资源、寻求指导……
|
||||
|
||||
你有看出上面这四项工作在工作对象上的差异吗?下面我们一起按顺序来看看,它们打交道的对象发生了哪些变化:
|
||||
|
||||
第一,技术开发工作,主要和客观事物、自然规律打交道。客观事物和自然规律的特点就是确定性、精确性和稳定性。也正是对这些特性的掌握程度,才能体现出我们对于客观世界的认知水平。对于这些客观的、稳定的特性和规律,我们的信念是认识它、掌握它、遵循它和利用它。所以,精确、严谨、稳定,以及按照规则办事、讲逻辑而非情感和感受,是技术人的基本哲学。而且,越是优秀和出色的技术人,这些特质就越是明显。
|
||||
|
||||
不过,接下来“悲剧”就发生了,因为这些优秀和出色的技术人,同时也是上级提拔管理人才的重要人选。而相对于稳定、客观的技术来说,人是非常不稳定的因素。我们赖以成功的最拿手的改造这个世界的方式和手段,在应对人的时候却很可能变得狼狈不堪。
|
||||
|
||||
第二,项目管理工作。虽然项目管理不可避免地要跟各个角色的人打交道,但这项工作无论是目标,还是过程,核心都是做事,都是基于规则和规范的。换句话说,还是可以照规矩办事的。技术人从编程语言和技术框架的规则,转换为项目管理的流程和规范,对于价值观的挑战还不是颠覆式的,精确性、规范性、确定性依然可以很好地发挥价值。
|
||||
|
||||
虽然要不断地开会、沟通,不得不和人打交道,但是依然是在一个有规则的大框架下工作,“感觉还好”。正因为如此,项目管理是很多技术管理者的拿手好戏。在我统计过的 500 多名技术管理者中,“项目执行和交付”这个主题,都是毫无悬念地排在“技术管理者最擅长的管理主题”的榜首,而且大幅度超过其他主题。我想,这绝非偶然。
|
||||
|
||||
第三,和下级合作。如果说项目管理还可以大幅度地依赖规则和规范来搞定的话,那么和下级的合作和沟通就变成了完全和人打交道了。人大概是这个世界上最不稳定的“因素”了,自然性、社会性、情感性交织在一起,再加上无时无刻的相互影响和波动,就别指望有什么流程和规则是可以用于和很多人的相处了,即便是和某个确定的人相处,都很难摸到规律,冲突和矛盾不断。不信的话,你看看网上有多少情感专家、教育专家就知道了。
|
||||
|
||||
而做了管理者,要和一群人相处,如果说安排他们做事还有些规矩可以用的话,那么员工激励就很难用规范和规则来实现了。因为,我们在第 27 篇文章中已经提到过,流程和机制是用来保障工作的“下限”的,而激励是激发团队工作“上限”的,所以,员工激励作为很“艺术”的一个管理主题,被众多的技术管理者列在了“最具挑战管理主题”的前三。我想,这一样绝非偶然。
|
||||
|
||||
第四,和上级合作。从规则感和掌控感而言,和下级合作至少有一个因素可以利用,即你的职位和角色带来的职权。从权力角度讲,因为下级向你汇报,你对他们的工作有分配、知情、评价的权力,你可以主导团队的一些规则和文化。从视野角度讲,团队成员的工作都在你的视野范围内,所以你会有一种掌控感。因此,和下级的合作,虽然已经只有很少的确定性的因素和手段可以用了,却还不是完全没有。
|
||||
|
||||
但是,和上级的合作,对于很多技术管理者来说简直就是“噩梦”了。自己很多任务是上级来安排的,这就很被动;上级比自己视野开阔,很多时候揣摩不透上级的意图,但是还不能不关心;自己需要的很多资源和支持都要向上级申请,但不见得能申请到;只能给上级提供建议,但是对方还常常不会采纳……各种各样的“不确定性”弥漫在每天的工作当中。
|
||||
|
||||
而且,上级,就是这么一个完全不受自己掌控的“事物”,却来评价你的工作做得好还是不好,并且还很大程度上决定着你的成长和发展。于是你发现,你最在乎的东西,却在最不可控的人手里……这让写代码出身的技术管理者们情可以堪呢?上级和代码完全就是两个世界的事物啊。
|
||||
|
||||
如果说和下级合作,价值观已经受到了一些挑战,那么和上级合作,工程师时代赖以成功的信念和价值观简直就被完全颠覆了。我想,这就是向上沟通之所以会成为技术管理者们“最头痛的管理主题”之最的原因吧!
|
||||
|
||||
既然,我们现在知道了,管理沟通让我们技术管理者们痛苦的主因是确定性和规则性的减弱,不确定性的大幅度上升。那么,我们能否从和人沟通这个不稳定的工作之中,找到一些稳定的因素呢?答案是有的,我们可以通过如下这个沟通框架来仔细探讨。
|
||||
|
||||
|
||||
|
||||
“果见管理沟通框架”
|
||||
|
||||
从上、下两个红框可以看出,这个框架主要分为上、下两个部分:上面的部分是由“目的”“内容”和“通道”三个部分套在一起组成的,属于“沟通”的主体部分;而下面是“影响力”部分。为什么要这么分呢?那我们具体来说说。
|
||||
|
||||
首先,我们看看“目的”。这里的“目的”显然指的是沟通目的。做任何工作都有一个初衷和目的,管理沟通也不例外。你可能会说,管理沟通林林总总,每个沟通场景都有不一样的目的,这个问题如何探讨呢?实际上,仔细想想你会发现,沟通不外乎如下四个目的:
|
||||
|
||||
建立通道。即建立沟通关系和沟通渠道,说白了就是你要和谁建立沟通关系,以什么方式和频度进行沟通。这就很像两个技术模块相互通信要建立“连接”一样。你刚接手某个团队的时候,需要跟上级、下级和合作的同级都建立沟通和合作关系,即是如此。
|
||||
|
||||
同步信息。也就是把相互不了解的信息同步给对方,让对方知悉了解此事。这个目的在日常沟通中非常常见,比如同步目标、汇报进度、通知通报等,即属于此类目的。
|
||||
|
||||
表达情感。有的时候,沟通只是为了表达某种情感,比如表达焦虑和压力、快乐和感谢,以及成就感等等。此时沟通本身就成了目的。
|
||||
|
||||
输出影响。在工作中,这类目的的沟通也是非常多的,比如提出建议希望对方采纳、管理上级的预期、和员工沟通绩效、向上级申请资源等等,都是希望别人能够采纳和满足自己的观点和诉求,从而达到输出自己影响的目的。
|
||||
|
||||
以上是沟通的四个目的。无论是向上沟通、向下沟通还是横向沟通的各个场景,你会发现都可以纳入到这四个沟通的目的中来。
|
||||
|
||||
其次,我们看看“内容”。对于一次沟通来说,清楚了沟通的目的,也审视了沟通的通道,接下来就是组织沟通“内容”本身了。内容的有效传递是很多管理沟通课程的探讨对象,大量的沟通工具、技巧和流程,都是为了解决信息的“不失真”,以确保双方领会对方的确切意图。关于沟通工具和技巧的部分,我们将在下一篇文章中介绍。
|
||||
|
||||
再次,我们看看“通道”。前面我们提到,建立通道是沟通的四大目的之一。实际上,无论是不是作为沟通的目的,建立和审视沟通通道,是每次沟通都必须要做的,因为沟通通道是我们沟通的前提和基础。一般来说,沟通通道或叫沟通机制的建立,从四个要素着手:沟通意愿、事务需求、沟通风格和信任关系。具体如何建立良好的沟通通道呢?我们也会在后面的文章中详细探讨。
|
||||
|
||||
最后,我们看看“影响力”。你可能会说,我们不是在探讨沟通吗?怎么就把影响力也扯进来了呢?我想说,我们通常所说的“管理沟通”,很多时候重点并不在“沟通”上,而在“管理”上。比如我们常常挂在嘴边的“绩效沟通”,这个沟通问题的核心其实在如何做绩效管理上,沟通只是绩效管理的一环而已。
|
||||
|
||||
还有一种情况,管理沟通的核心也不在“沟通”上,那就是当你沟通的目的是“输出影响”的时候。你是否发现有的时候,你用尽了各种沟通的技巧和工具,却依然无法“影响”对方的决策和观点?这是因为,你对他的影响,只会有一小部分来自于沟通本身,而真正决定你能否影响对方的,是你对他的“影响力”。这个影响力包含了职权影响力和非职权影响力。关于影响力是如何发挥作用的,以及如何提升自己的影响力,我们也会在后面的文章中详细探讨。
|
||||
|
||||
通过对上述沟通框架的介绍,我们可以看到在沟通这个不稳定的事物中,有哪些因素是稳定的了吗?我觉得至少有这样四个:
|
||||
|
||||
管理逻辑。管理沟通问题,其实需要从管理逻辑和沟通方法两个视角来应对和处理。所谓的管理逻辑,就是从管理角色认知和管理方法来看待该问题处理的逻辑。这是可以随着管理认知和管理经验的不断积累而不断提升的,你的管理逻辑和管理判断力会越来越可靠,应对管理沟通也就越来越有掌控感,所以这是相对稳定的一个因素。
|
||||
|
||||
沟通通道。一个沟通通道的水平,主要体现在通道是否稳定,以及沟通是否顺畅这两点上。决定这两点的,就是你和对方的信任水平和默契程度,这两个要素也是会持续积累的,而且积累的水平越高,沟通通道的品质就越高,故而沟通成本就越低。因此,这也是管理沟通中,比较稳定可靠的一个因素。
|
||||
|
||||
工具流程。沟通有很多的工具、技巧、流程,对于最常见的向上、向下、横向这样特定的沟通场景,如果你能够持续掌握一些适合自己的工具和流程,那么这些你可以熟练使用的工具和流程,就变成了一个相对稳定的要素。
|
||||
|
||||
影响力。影响力的积累不是一天两天的事情,而其发挥作用的时候也是非常稳定的,尤其在说服影响的沟通中,你有多大影响力,基本就决定了你能影响什么样的人,以及多大的事情。所以,这也是沟通可以依靠的稳定的因素。
|
||||
|
||||
好了,上面我们分析了管理沟通对技术管理者造成重要挑战的原因;介绍了一个管理沟通的框架;并归结出相对可以“稳定依靠”的四个因素。
|
||||
|
||||
你是否觉得管理沟通这事儿有迹可循了呢?至少,你已经找到了一些方向和落脚点,可以让你满怀信心地去学习和积累,不是吗?
|
||||
|
||||
|
||||
|
||||
|
93
专栏/技术管理实战36讲/29沟通经常鸡同鸭讲,说不到一块怎么办?.md
Normal file
93
专栏/技术管理实战36讲/29沟通经常鸡同鸭讲,说不到一块怎么办?.md
Normal file
@ -0,0 +1,93 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
29 沟通经常鸡同鸭讲,说不到一块怎么办?
|
||||
作为一个团队的管理者,你不可避免地要把很多的时间和精力花在与各种各样的合作者沟通上。而且,随着团队规模的不断扩大,以及级别的不断提高,对沟通能力的要求也会“水涨船高”。
|
||||
|
||||
在做工程师的时候,和你沟通合作的往往都是你熟悉的一群人。走上管理之路后,你会发现,随着做管理的时间越来越长,跟你打交道的人会变得越来越五花八门,什么样的人都有。沟通中常常会遇到的一个情况就是,你说你的、他说他的,好似“鸡同鸭讲”,用东北话说就是“费老劲了”!这怎么办呢?
|
||||
|
||||
显然,这类问题,说到底是一个沟通效率的问题,即,无论是同步信息也好,还是影响说服也好,如何才能轻松搞定,高效达成呢?
|
||||
|
||||
关于沟通效率,我们可以从两个角度着手去提升:
|
||||
|
||||
上篇文章中我们提到,沟通通道的品质,主要是从稳定性和效率来衡量的。
|
||||
|
||||
所谓稳定性,就是这个通道是稳定可靠的,不会动不动就谈崩或断了联系,即使有点误会,双方也能够相互包容和谅解。在这个因素上,信任关系和信任水平就起了决定性作用。当你被对方充分信任的时候,你会发现很多不必要的沟通都可以省掉了,这种合作当然高效。
|
||||
|
||||
所谓效率,就是这个沟通通道的效果和成本之比。所谓高效,是指双方只需要非常少量的成本,就可以达成很好的沟通效果。在这个维度上,双方的默契程度起了决定性作用。当你们之间高度默契的时候,一举手一投足、一个眼神一个表情、只言片语就可以心领神会了,所谓“心有灵犀一点通”即是如此,相信你曾经有过这种神清气爽的体验。只是,这种体验换一个人沟通就可能会消失,因为你不会和每个人都拥有这种默契。毕竟两个人的默契,不是一朝一夕产生的,需要长时间的磨合和调适。
|
||||
|
||||
所以,信任也好,默契也罢,都体现了沟通通道品质的这两个因素是需要长期经营的,它们更像是用来体现结果的,而不是可以灵活使用的手段。那么,如何在这两个因素上进行积累,以达成那样的结果呢?以及,我立刻就要解决鸡同鸭讲、沟通低效的问题,该怎么办呢?
|
||||
|
||||
这就是我要说的第二个角度,即,靠沟通技能,使用沟通工具和沟通技巧来解决当下的沟通问题。有什么好用的工具吗?我们先来看一个真实案例:
|
||||
|
||||
(背景)某项目原定于 6 月 7 日完成,可是实际到 6 月 9 日才完成,于是研发经理刘备就找负责的工程师张飞沟通。
|
||||
|
||||
刘备说:“咱们这个项目按计划 7 号完成,你 delay 了两天也不跟我说一声,我是最后一个知道的!”
|
||||
|
||||
张飞说:“我跟负责项目的产品经理孔明说了啊,他也觉得没问题,大家没有异议就行了呗,项目不是成功发布了吗!”
|
||||
|
||||
刘备说:“那也应该提前跟我说一声啊,我如果提前知道就会让子龙来帮你,最后也不至于 delay 两天。”
|
||||
|
||||
张飞说:“我觉得我能搞定,你不要动不动就让子龙来帮我,这是对我的不信任。要不是最近孩子生病我也不会 delay。即便 delay 了,我也和合作方都沟通好了,什么事都没耽误。而且我已经尽最大努力了啊,你还要怎么样呢?信不过我的话,下次这样的项目你交给二哥去做吧!”
|
||||
|
||||
刘备说:“我就是想让你提前告诉我一声,你急啥!”
|
||||
|
||||
张飞说:“你先急的好不好!”
|
||||
|
||||
……
|
||||
|
||||
好,案例我们先看到这里,你觉得接下来会发生什么事情呢?如果你是其中的刘备或者张飞,接下来你会怎么沟通呢?
|
||||
|
||||
在日常的管理沟通中,类似的场景数不胜数。有的会互怼下去,僵持不下;也有的会选择逃避,敷衍了事。但是这都达不到彼此沟通的意图和目的。那么,怎么沟通才能达到彼此的目的呢?
|
||||
|
||||
下面,我介绍一个工具,在沟通中,我们可以使用它来对齐彼此的信息、感受和意图,具体如下图所示:
|
||||
|
||||
|
||||
|
||||
基于“3F”倾听的沟通层次图
|
||||
|
||||
学过教练技术的同学一眼就可以看得出,这个工具的前三步,其实就是“3F”倾听,只是在相互倾听的基础之上,又走到了第四步,去确认有没有达成共识。
|
||||
|
||||
所谓“3F”倾听,就是要从对方的谈话中听出三层信息:
|
||||
|
||||
第一,事实信息(FACT)。即,对方说了哪些事实性信息?和你掌握的信息相比有没有什么不同?这是沟通的第一层,也是最基础的一层。如果双方连基本的事实信息都不一致,达成有效的沟通结果就无从谈起了。
|
||||
|
||||
我们来看看,在上述案例中,刘备和张飞的沟通是基于一致的事实信息吗?不难发现,对于这三点重要的事实:
|
||||
|
||||
双方都认同,是没有异议的,可见他们沟通的基础信息没有分歧。
|
||||
|
||||
由于事实信息的客观性,只要肯沟通,这层信息是最容易达成一致的。所以,在发生意见和看法不一致的情况下,首先来对齐事实信息是必要且有效的。当然,随着双方背景信息的不断同步和默契度的不断提升,在一些沟通中该步骤常常被省略。但是,被省略并不意味着不重要,一旦发生分歧的时候,就需要把这层内容拿出来检视和对齐一下了。
|
||||
|
||||
第二,感受和判断(FEELING)。即,对于上述事实信息,双方是什么样的感受和判断。由于每个人生活的环境不同,所处的角色不同,惯用的思维方式不同,沟通的初衷也不同,所以,即便是针对同样的客观事实,双方的感受和看法也常常是不同的。这就是沟通中最容易发生分歧的地方。
|
||||
|
||||
我们还是通过前面的例子来看,基于同一个事实,刘备和张飞各自的感受和判断是什么。
|
||||
|
||||
在刘备看起来:如果张飞提前告诉他这个风险,这个项目本可以不用 delay;而且,自己作为张飞的直接上级,最后才知道有这回事,无论怎么说,自己和张飞之间的协作方式都需要改进。
|
||||
|
||||
在张飞看起来:delay 两天确实不应该,但也是不可抗拒的客观情况造成的,而且为了不给刘备添麻烦,自己主动协调好了各个合作方,并保证项目成功发布,刘备不但不领情,还一副信不过我的样子,显然在他眼里子龙更能干。
|
||||
|
||||
当然,我不是刘备,也不是张飞,这些内心的感受和观点,也是我采访他们之后得知的。你可以看到他们对于同一个事实,双方的感受、判断和期待是很不一样的,之所以会发生后面的情绪对抗,其实就是从这里开始的。
|
||||
|
||||
实际上,我们常说的“默契”,就主要体现在沟通双方对彼此的感受和判断逻辑的理解程度上。因此,你们越是熟悉彼此的立场、思维方式和沟通风格,就越是容易和对方达成默契。所以,默契是在不断合作的过程中磨合出来的,很难自然而然地形成。
|
||||
|
||||
那么,在还没有这种默契的时候该怎么办呢?难道就要像刘备和张飞一样争执和互怼吗?
|
||||
|
||||
我的回答是,有意识地去询问,而不是默认对方一定清楚自己的逻辑和判断。怎么询问呢?如果我是刘备或者张飞的话,我可以这样说:“对于这些事实情况,我的看法是这样的……我想了解下,你的看法是什么呢?”这样一确认,就避免了“猜测”和“想当然”带来的各种各样的误会。
|
||||
|
||||
第三,意图(FOCUS)。即,对方沟通的焦点在哪里,各自为了达到什么意图和目的。每一次沟通,都是基于某个特定的目的和初衷的,无论这个问题你有没有在沟通之前去刻意厘清,都是如此。
|
||||
|
||||
上一篇文章我们提到,沟通的目的不外乎四个:建立通道、同步信息、表达情感和输出影响。显然,在前面的案例中,刘备沟通的目的和意图是想说服张飞,让他在以后的工作中,提前通报风险,而不是瞒而不报,他从来没有质疑过张飞的能力。而张飞的目的和意图是什么呢?他在表达一种不满,这种不满情绪的背后,是他希望刘备可以给他一些认可和鼓励,并信任他的能力。
|
||||
|
||||
所以你会发现,他们的意图并没有矛盾和冲突,这场沟通,完全可以达到彼此满意的结果。只是因为他们在沟通中,不在一个频道上,把事实、判断、感受、责任、原因、方案等统统揉到一起来说了:你讲事实他说原因,你说原因他说感受,你说感受他说逻辑,你说逻辑他说责任,你说责任他说解决方案,你说解决方案他说困难……最终就成了“鸡同鸭讲”,互相的不理解和不认同。
|
||||
|
||||
通过用“3F”倾听和沟通层次图对上面的案例进行分层拆解,你不难发现,如果我们在沟通中,有意识地分事实、感受、意图这三个层次去理解对方的话,并且从这三个层次分别和自己的事实、感受、意图做一个对应,就可以减少很多不必要的误会,同时避免情绪对抗,从而达成有效的沟通结果。
|
||||
|
||||
对于一个经常沟通的对象,你可以用这个工具,在和对方不断地倾听与确认中,形成默契;在不断地默契合作中,提升信任。当信任和默契程度越来越高,也就是沟通通道品质越来越好时,很多工具和技巧也就可以省略和简化了。于是,你也就知道了,越是在信任度和默契度低的情况下,这个工具越有用武之地;越是在人多口杂的时候,越容易让大家在同一个框架下达成沟通成果。
|
||||
|
||||
所以,如何高效顺畅地沟通呢?用一句话来说就是,通道品质好就靠通道,通道品质不好就靠沟通技术。用什么沟通技术呢?从基于“3F”倾听的沟通层次图开始练起吧,练到“心中有剑,手上无剑”,很多沟通困境也就不攻自破了。
|
||||
|
||||
|
||||
|
||||
|
73
专栏/技术管理实战36讲/30如何掌控自己的情绪,以及如何管理情绪化的员工?.md
Normal file
73
专栏/技术管理实战36讲/30如何掌控自己的情绪,以及如何管理情绪化的员工?.md
Normal file
@ -0,0 +1,73 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
30 如何掌控自己的情绪,以及如何管理情绪化的员工?
|
||||
在我们的管理工作中,不可避免地会碰到一些容易情绪化的合作者,可能是我们的下级、我们的上级,甚至可能是我们自己。大家都不喜欢和情绪化的人打交道,碰到坏情绪的人唯恐避之不及,敬而远之。可是,如果是自己或者自己的上、下级,那就避无可避了。那么,有没有办法可以让自己不要动不动就情绪化呢?下面我们就仔细地来聊一聊。
|
||||
|
||||
要探讨情绪管理问题,我们就需要先界定一下我们所说的“情绪”是指什么。
|
||||
|
||||
显然,情绪每个人都有,并不是那些情绪化的人所特有的。虽然情绪如此普遍,但要想探讨清楚它却很难。目前学界公认的人类的基本情绪有 4~10 种,其中被广泛认同的有恐惧、生气、伤心、厌恶、惊喜和高兴等。
|
||||
|
||||
对于管理沟通来说,我们倒没有必要去探讨所有的情绪,只需要去关心最令我们头疼的情绪即可。显然,大家说的情绪管理,基本上都是对于情绪“激动”“生气”甚至是“愤怒”的管理;我们所说的情绪化,一般也是指某个人特别容易情绪激动,并且常常把这种情绪带入到工作中。因此,我们今天探讨情绪管理,也主要围绕“激动”或“愤怒”来展开。
|
||||
|
||||
话说回来,有那么多种情绪,为什么在工作中,大家唯独对于激动或愤怒这么耿耿于怀呢?我想,至少有两个原因:
|
||||
|
||||
愤怒是一种“战斗”情绪,自带攻击属性,非常容易引发另一方高度紧张地回应。无论是选择对抗、防卫或逃避,潜意识里感受到的都是威胁,如此,便妨害到“生存和安全”这个人类最基础的需求层次,并由此对合作关系造成很强的破坏性,还容易传染。
|
||||
|
||||
从愤怒中“跳出来”非常困难。相信你曾经有过这样的体验,面对一个正在愤怒中的人,你说什么他都听不进去,能够不迁怒于你,已经是谢天谢地了。
|
||||
|
||||
那么,为什么从愤怒中抽离出来这么困难呢?这里就不得不说一下人的“三层脑结构”。
|
||||
|
||||
美国学者麦克林(Mclean)根据大脑演化过程提出了三个脑层次的理论:最里面的是“爬行动物脑”,这部分脑是从爬行动物那里继承下来的,控制着人本能的、无意识的、瞬间反应的行为,属于“生存式大脑”;中间的这层大脑,是从哺乳动物遗传下来的部分,控制着情感和情绪,并沉淀和保持长期形成的习惯模式,这种模式反应也很快速,称为“情绪脑”;而最外层的大脑,是智人阶段才进化出来的,控制着视觉、想象力、辨别力、系统思考等,称为“理性脑”。这“三层脑结构”的示意图如下:
|
||||
|
||||
|
||||
|
||||
“三层脑结构”
|
||||
|
||||
显然,我们日常所进行的分析思考、设计规划、沟通交流等,都是基于“理性脑”工作的。虽然“理性脑”可以让我们做很多复杂的智力活动,但是响应优先级和响应速度却远远不及“情绪脑”和“爬行脑”。也就是说,“爬行脑”和“情绪脑”更容易中断“理性脑”的工作,而且一旦我们的大脑工作在“爬行脑”和“情绪脑”状态,就无暇顾及“理性脑”的工作了。这就是为什么人在盛怒之下,很难冷静思考和准确判断。
|
||||
|
||||
那么“情绪脑”和“爬行脑”会造成这么多负面情绪,而且也不如“理智脑”那么复杂和理性,是不是就成了大脑的“阑尾”呢?事实上,人能良好运转,大部分靠的都是无意识的、本能的行为,比如走路。而且,“爬行脑”和“情绪脑”的反应都很快,在遇到威胁和紧急情况的时候,它们能够立即做出反应,以最大程度地保证我们的安全。
|
||||
|
||||
所以,“爬行脑”和“情绪脑”是极其重要,不可或缺的。你不难发现,即使是“愤怒”这么令人头疼的情绪,它也有着非常积极的一面,比如它会让我们在面对威胁的时候充满勇气和爆发力,西方很多将军就利用这一点来做战前动员。所以“愤怒”并不是一个一无是处的“坏东西”,只是出现在不合理的场合,才会给我们造成困扰。
|
||||
|
||||
你也许会问,我们要讨论的是情绪管理,又不是研究脑科学,花这么多时间讲“三层脑结构”做什么呢?理由有三:
|
||||
|
||||
你要想掌控和管理自己的情绪,不了解它又如何管理呢?所以,你要先认识它。
|
||||
|
||||
如果你对于情绪,比如愤怒,总是想着回避和嫌弃它,又怎么能够管理它,和它做朋友呢?所以,你还要看到情绪的积极意义,并接纳它的存在,正视它是管理它的前提。
|
||||
|
||||
清楚了从愤怒难以恢复理智和平静的原因,实际上你也就知道了管理愤怒和激动的方法。即,用一根“管子”打通“理智脑”和“情绪脑”,当情绪控制大脑的时候,好让理智也有机会参与进来。这里这根“管子”,就是建立对情绪的觉察。对情绪的觉察,是情绪智力的核心能力,是跳出情绪的钥匙。一旦你觉察到自己正处在一种不理智的愤怒当中,只要你愿意,就会有各种各样的方法和策略去消除它,并分辨得失,做出理智反应。网上和很多情绪管理书籍上谈论的应对措施,大都是接下来这个阶段的应对方法,若你感兴趣也可以对照自己的具体情况去查查资料。
|
||||
|
||||
既然找到了情绪管理的钥匙,那么接下来,我们就探讨一下,如何拿到“跳出情绪的钥匙”,也就是如何建立觉察,并强化这个觉察,让我们越来越容易从情绪中抽离出来。
|
||||
|
||||
首先,我们先在理智的情况下为自己建立一个觉察,审视自己:“我是否在发怒呢?”这是基于这样一个认知,即“在愤怒的情绪下处理问题容易误判,如果有情绪,就先处理掉情绪再处理事情”。
|
||||
|
||||
接下来,每次处理一个紧要的事情前后,都默默审视一下自己:“我是否有发怒呢?”也就是让这个意识不断强化,形成一种条件反射或模式,以至于一发怒就会去觉察自己是否在生气。如果你写过“钩子”程序,你就会发现,这个觉察的模式就好像是挂载一个“钩子”,一旦“钩子”被触发,后面跟上处理程序就可以了,显然这个处理程序就是情绪应对的步骤。久而久之,当你能够用这个理智的“钩子”去控制情绪的时候,你突然发现,情绪不再是一头难以驯服的野兽,反而变成一个“工作助手”了。
|
||||
|
||||
当然,这个模式形成的过程,并不容易,否则就不会称为“模式”了。除了自己强化,还有几个外部力量可以进行协助。
|
||||
|
||||
可以靠经常能关注到的一个随身物件来提示。比如你的手环、戒指,甚至是手上的一个伤疤,只要你能时不时关注到,就可以。一旦看到这个物件,你就问一下自己“我是不是在发怒”,这也是一种觉察。
|
||||
|
||||
每天写觉察日记,反思自己在情绪管理方面是否有所失误。我身边就有伙伴用这种方式并取得了比较好的效果。
|
||||
|
||||
可以和伙伴约定,请他帮忙提醒。一旦他发觉你情绪不对,都可以当场或事后提醒你,来加强觉察。
|
||||
|
||||
用你的重要关切来提醒。比如,你可以和你的上级约定,把这个季度的情绪化频次作为一项 KPI 纳入自己的《绩效计划》,从而让你心里总是悬着一根弦来不断提醒自己要注意情绪。细心的你一定发现了,这个方法显然也可以用于帮自己的下级来提升情绪管理的能力。事实上,我就用过,并且取得了很好的效果。
|
||||
|
||||
借助上面提到的觉察方法,只要不断地练习,假以时日,你就会发现,你不但可以觉察到自己的情绪了,甚至还可以发挥它的力量,为你所用。
|
||||
|
||||
最后,为方便你管理自己的情绪,抑或者是帮你的下级和伙伴去提升情绪掌控能力,我梳理了整个步骤并总结为如下:
|
||||
|
||||
认知它。了解它是怎么产生的,以及怎么发挥作用的。如果是帮下级改进,可以先给他讲讲“三层脑结构”的事情。
|
||||
|
||||
认同它。接纳并疏导自己的情绪压力,而不是压抑它。看到它消极的一面,也要看到积极的一面,并和它交朋友。如果是帮下级改进,切忌一味批判他的情绪化,而是引导他看到情绪的两面性。因为很多情绪化的人,往往发怒之后会后悔,希望控制自己的情绪,只是控制不住,这个时候就会全面否定自己的情绪。
|
||||
|
||||
觉察它。建立对情绪的觉察,并用我们上面提到的方式不断强化,给予足够的耐心不断练习,直到它变成一种下意识的反应。如果是帮下属改进,你可以和他约定如何提示他,在他自愿的情况下,也可以像我一样,纳入 KPI 管理。
|
||||
|
||||
通过上面的步骤,就可以帮自己或者合作伙伴不断提升情绪管理的能力了,我曾教练过五六位情绪激动或易怒的下属,屡试不爽。你要不要也来试一试呢?
|
||||
|
||||
|
||||
|
||||
|
139
专栏/技术管理实战36讲/31我各方面做得都很好,就是做不好向上沟通.md
Normal file
139
专栏/技术管理实战36讲/31我各方面做得都很好,就是做不好向上沟通.md
Normal file
@ -0,0 +1,139 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
31 我各方面做得都很好,就是做不好向上沟通
|
||||
在前面第 28 篇文章中我们提到,根据实际统计结果显示,向上沟通是技术管理者们最挑战的管理主题之一。那么具体是哪些事情,让管理者们感到头痛呢?
|
||||
|
||||
基于上百个关于向上沟通的问题反馈,我发现有如下四类问题是最为普遍的。
|
||||
|
||||
第一类:和上级能不聊就不聊。主要说法有:
|
||||
|
||||
“上级太忙了,我的事情好像没有那么重要,等他闲了再说吧。”
|
||||
|
||||
“找不到上级,他很少在工位,每次碰到他都急匆匆地走开,没机会聊。”
|
||||
|
||||
“把领导交代的工作做好就行了呗,有事没事找领导聊啥,最讨厌有事没事讨好领导!”
|
||||
|
||||
“总是觉得和上级有距离感,很难聊到一块儿。”
|
||||
|
||||
“每次见了上级说话都不利索,能用邮件沟通就写邮件吧。”
|
||||
|
||||
第二类:拿捏不好该不该和上级聊的分寸和尺度。主要说法有:
|
||||
|
||||
“最近取得了一个不错的成绩,要不要和上级说一说呢?”
|
||||
|
||||
“感觉自己离技术越来越远,有些焦虑,是不是可以把上级当作朋友来聊聊呢?”
|
||||
|
||||
“某项目很可能会 delay,上次和领导打过招呼了,他不置可否,随着形势越来越严峻,我要不要再跟他说一次呢?”
|
||||
|
||||
“我和合作者有些隔阂,不知道适不适合告诉上级。”
|
||||
|
||||
“上级招我们来是解决问题的,而不是来给上级制造问题的!”
|
||||
|
||||
第三类:很难领会到上级的意图。主要说法有:
|
||||
|
||||
“上级告诉我这个项目要加紧了,可是要加紧到什么程度呢?”
|
||||
|
||||
“上级把这个工作交给我负责,却又安排别人参与进来,这是不信任我吗?”
|
||||
|
||||
“上级让我去做一个调研,也没有说什么时候要结论,到底急不急呢?”
|
||||
|
||||
“老板到底在想什么呢?他最近突然不找我了……”
|
||||
|
||||
第四类:如何影响上级的一些观点和决策。主要说法有:
|
||||
|
||||
“老板常常有不靠谱的需求和新想法,我就不知道该如何柔和又不失礼貌地拒绝。”
|
||||
|
||||
“上级对项目进度的需求总是很高,如何管理上级的预期呢?”
|
||||
|
||||
“有个项目需要向领导申请增加人力,如何跟他说呢?”
|
||||
|
||||
“上级总是不采纳我的建议,有何良策吗?”
|
||||
|
||||
“上级不懂业务,还喜欢拍板做决策,怎么应对?”
|
||||
|
||||
怎么样,上面四类问题,有覆盖到你的情况吗?
|
||||
|
||||
由于向上沟通永远是你和上级的“私事”,所以我们无法给出一个普遍适用、一劳永逸的标准答案,也无法穷举所有的向上沟通的场景。但是,我们来逐个分析一下这四类最集中的问题,也不失为一个好的探讨方法,不是吗?
|
||||
|
||||
接下来,我们就逐类来分析一下。
|
||||
|
||||
第一类,关于“和上级能不聊就不聊”。你不难发现,无论是所谓的“上级太忙了”,还是“找不到上级”,甚至干脆认为就不该和上级沟通,归结起来,都是没有意识、意愿或能力和上级建立良好的“沟通通道”。
|
||||
|
||||
那么如何建立良好的沟通通道呢?你可以从以下四个方面来着手和审视。
|
||||
|
||||
第一,沟通意愿。这是基本前提。作为一名工程师,你不主动和上级沟通问题也不大,因为上级一般会有意识地主动和你沟通。但是,如果作为一名管理者,你还不主动和上级沟通的话,那就相当于已经上大学了,还要家长和老师逼着做作业一样。又如何指望你能带领别人往前走呢?
|
||||
|
||||
实际上,在我和中层管理者聊他们对下属的期待时,他们大多都会明确表示,希望我和初级管理者们澄清一个事情,那就是:“上级默认是需要管理者们主动向上沟通和反馈的,而非默认不需要。”
|
||||
|
||||
关于沟通的意愿,你可以首先审视一下你的角色:你是一名工程师还是一名管理者?然后再审视下自己的初衷:你是为了自己而沟通,还是为了团队去沟通?
|
||||
|
||||
通过问自己这两个问题,让你的角色给你沟通的力量和动力。关于角色认知,我们前面的文章已经有过明确的探讨,这里不再赘述。
|
||||
|
||||
第二,事务特点。即,根据事务的特点,比如是否重大、是否紧急、是否敏感、是否正式等,来确定沟通的方式和频次。这很容易理解。
|
||||
|
||||
第三,沟通风格。如果说审视事务的特点,是根据“事”来选沟通方式,那么审视沟通对象的风格,就是根据“人”来选择沟通方式。探讨沟通风格和管理风格的工具比较多,比如大家都熟悉的 DISC,以及盖洛普的“四大优势领域”等,如果感兴趣你也可以去了解和学习一下,核心是根据沟通对象的风格特点,来选用你们更高效和易接受的沟通方式。
|
||||
|
||||
第四,信任关系。如果说前面提到的沟通意愿、事务特点和沟通风格,都是为了鼓励你主动加强沟通的话。那么对于你和上级信任关系的审视,就是让你看看,是否可以简化沟通。比如你原本需要长篇大论的汇报,对于默契度很高的上级,可能也就是一条消息的事儿;你原本需要多次沟通的问题,对于信任度很高的上级,可能只要简单一句话,甚至都可以免掉沟通。
|
||||
|
||||
所以,你需要花多大精力去准备沟通,很大程度上取决于你和上级的沟通通道的品质。也就是前面的文章中我们提到的信任和默契。信任决定着你们沟通关系的稳定性,默契代表着你们沟通关系的效率和性能。
|
||||
|
||||
好了,你如果从沟通意愿、事务特点、沟通风格、信任关系盘点下来,还是不需要和上级去沟通,那么这种不沟通就是你有意识的不沟通,它可能带来的破坏性和损失也就可控了,这和消极的不沟通,是两码事。
|
||||
|
||||
第二类,关于“拿捏不好该不该和上级聊的分寸和尺度”。我曾经在课堂上做过这个练习,把这些问题作为候选清单,让管理者们选出他们认为需要沟通的选项,结果大家给出的建议五花八门。如果我是个管理者,听到这么多建议,估计会更晕了。
|
||||
|
||||
为什么不同的管理者的看法会有这么大差异呢?原因是,每个人在评判“该不该聊”的时候,都是基于自己的管理常识(common sense),而每个人在和不同的上级打交道的过程中,形成的常识是不同的,所以会给出不同的答案。
|
||||
|
||||
在我看起来,大多拿捏不好“该不该聊”这个问题的情况,都是由于还没有厘清自己想通过这次沟通拿到什么,即沟通的目的和初衷不清晰。很多管理者甚至不清楚该如何来描述自己的初衷。
|
||||
|
||||
我这里给出一个参考:你是否还记得在前面第 28 篇文章中,我们提到“沟通总体上有四个目的”的说法吗?这四个目的就是建立通道、同步信息、表达情感和输出影响。而你和上级想要沟通的目的,也跳不出这四个,只是你需要明确“就什么事”达到上述四种目的中的一个或几个。
|
||||
|
||||
比如我们来看前面的案例:
|
||||
|
||||
“最近取得了一个不错的成绩,要不要和上级说一说呢?”这时你可以问下自己:“我是想就此向上级表达我很有成就感?”
|
||||
|
||||
“感觉自己离技术越来越远,有些焦虑,是不是可以把上级当作朋友来聊聊呢?”这时你可以问下自己:“我是想就此寻求上级的支持和帮助,成功地让他给我一些建议?”
|
||||
|
||||
“某项目很可能会 delay,上次和领导打过招呼了,他不置可否,随着形势越来越严峻,我要不要再跟他说一次呢?”这时你就可以问下自己:“我是想就这个问题再和他做一次信息同步,如果有可能,我会进一步说服他给我提供一些资源和支持吗?”
|
||||
|
||||
……
|
||||
|
||||
在这类问题上,我们无法去评判哪个目的更重要,或者更应该和上级聊,因为我们不是当事人,只有当事人自己才最清楚这个目的对他来说意味着什么。所以,我唯一能做的,就是给你这个方法帮你厘清沟通的目的,至于每个目的有多重要,你还可以问自己两个问题:
|
||||
|
||||
然后,你根据自己的目的,做出自己的选择和判断吧!
|
||||
|
||||
第三类,关于“很难领会到上级的意图”。对于沟通意图的领会,其实就是对于信息的无失真传递和接收。但是你知道,由于每个人都有自己一套独特的认知体系,所以对于同一个概念的理解都会不同。那又怎么可能做到无失真的领会呢。
|
||||
|
||||
相信你也听过这样一个说法:看似是两个人之间的沟通,其实至少是“四个人”之间的对话,哪“四个人”呢?也就是:你想表达的、你实际表达的、对方听到的和对方对于听到内容的理解,这其中每一步传递都会造成失真,所以很难领会到对方的真实意图也就情理之中了。
|
||||
|
||||
那么如何降低这种失真所带来的沟通误差呢?在第 29 篇文章中,我已经给出了方案:通道品质足够高的话就靠沟通通道;如果沟通通道品质不高,信任和默契程度不够,就需要靠沟通工具来对齐了,沟通层次图及“3F”倾听是个不错的工具。
|
||||
|
||||
另外,用一些“回放”的句式来确认,也是个好方法,比如你可以用下面的话来回放和复述你所听无误:
|
||||
|
||||
“你是不是这个意思,……”
|
||||
|
||||
“你看我理解的是否准确,……”
|
||||
|
||||
可别小看它,在沟通重要的事务,以及和不熟悉的人沟通时,这个小技巧能帮你避免大的沟通偏差。
|
||||
|
||||
第四类,关于“如何影响上级的一些观点和决策”。这是向上沟通中的一大类需求,无论是“希望上级接受自己的建议”或者“拒绝上级的不合理需求”,还是“调整上级的预期”或者“说服上级给予资源和支持”,归结起来都是让上级听从自己的看法和方案,即把自己的认知和期待输出给上级。所以,这类需求其沟通的目的就在于“输出影响”。
|
||||
|
||||
为了达到“输出影响”这一目的,你可能会根据上级的风格去选取合适的沟通方式,根据上级的关切去选取合适的内容和呈现逻辑,并根据上级的状态去选取合适的沟通时机,等等。我想说,这么做都没问题,而且有时会很奏效。可是,既然这个问题能够成为管理者们普遍头疼的事情,说明这些效果是有限的,因为问题还是依然棘手。
|
||||
|
||||
那么,如何才能有效地对上级实施影响呢?我给大家用下面的冰山模型做一个提示:
|
||||
|
||||
|
||||
|
||||
“说服影响”的冰山模型示意图
|
||||
|
||||
从上图你不难看出,说服一个人时,沟通技巧是在“术”的层面起作用;而对说服效果影响更大的因素,却是水面下的冰山,即“势”的部分,也就是你对他的影响力如何。
|
||||
|
||||
当你对他的影响力很小的时候,你的技术和方案再优秀,影响力也是非常有限的。举个例子,对于一个完全相同的建议,一线工程师提给 CEO,和 CTO 提给 CEO,极有可能是完全不同的结果。究其原因,就是你们两个对于 CEO 的相对影响力差别是很大的。也就是说,如果你要想有效地对上级实施影响和说服,你的影响力是至关重要的。
|
||||
|
||||
那么,该如何盘点和提升自己的影响力呢?我们下一篇文章再来继续探讨。
|
||||
|
||||
|
||||
|
||||
|
117
专栏/技术管理实战36讲/32横向沟通和非职权影响力.md
Normal file
117
专栏/技术管理实战36讲/32横向沟通和非职权影响力.md
Normal file
@ -0,0 +1,117 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
32 横向沟通和非职权影响力
|
||||
向上沟通、向下沟通和横向沟通构成了管理沟通的主体,所以我把它们称为管理沟通的三大典型场景。在上一篇文章中,我们已经探讨了向上沟通。今天,我们就来聊一聊横向沟通,也就是和没有直接汇报关系的合作方之间的沟通。
|
||||
|
||||
首先我们来看,横向沟通有哪些目的呢?既然横向沟通也是一种沟通,那么就不外乎前面我们提到的四个目的:建立通道、同步信息、表达情感和输出影响。在真实的横向合作中,你不难发现,大多都是以同步信息和寻求支持为目的。其中,寻求支持就是通过说服对方来支持自己,其目的也就是“输出影响”。
|
||||
|
||||
关于同步信息,对于技术出身的管理者们来说主要是意识层面的挑战。一般只要意识到了,大都就能做到,因为他们是信息传输方面的行家里手。所以,横向沟通更核心的挑战在于:对于没有汇报关系的合作者,如何获得他们的支持和帮助呢?
|
||||
|
||||
我的回答是,和向上沟通中希望“说法影响上级”一样,无非是靠沟通的“术”和“势”,而且重点在于“势”,即,你对对方有多大的影响力。
|
||||
|
||||
从探讨沟通话题的第一篇文章,到向上沟通,再到横向沟通,我们反复提到影响力的决定性作用,但限于文章篇幅一直没有展开,现在看来已经避无可避,是时候详细探讨一下影响力这个话题了。
|
||||
|
||||
影响力,是一种不使用强制性力量却能改变别人的看法和行为的能力。一般又分为职权影响力和非职权影响力。
|
||||
|
||||
所谓职权影响力,主要是指你的职位因素所提供给你的影响力。在我们工作中常见的是如下三个因素:
|
||||
|
||||
传统因素。即在社会传统意识和社会规范当中,对于上级的基本姿态是要服从的。所以人们对于上级有一种天然的服从感。
|
||||
|
||||
职位因素。即从组织架构的角度,由于上级对于下级有奖惩和评价的权力,使得下级对他们有一种敬畏感,从而更容易遵从上级。
|
||||
|
||||
资历因素。即有资历的人,在人们的眼中是值得敬重的。虽然在互联网领域里,已经很少提及论资排辈了,但不可否认的是,你新加入一家公司时,对于公司里资深的老员工常会有一种敬重感,这是人之常情。
|
||||
|
||||
|
||||
|
||||
职权影响力要素
|
||||
|
||||
虽然职权影响力是影响力的一个重要组成部分,但是我们只要能大体了解,或者知道什么是职权影响力就可以了,这并不是我们探讨的重点,因为这个影响力的发挥和发展,受到职位因素的影响比人为因素的影响更大。所以,我们还是来聚焦于我们通过努力可以提升的影响力,即非职权影响力。
|
||||
|
||||
非职权影响力,即,不是利用你的职位因素而提供的影响力。那么,非职权影响力有哪些因素呢?
|
||||
|
||||
在非职权影响力方面,美国社会心理学家罗伯特·B. 西奥迪尼的《影响力》可以说是殿堂级的著作,他主要从互惠、承诺一致、社会认同、喜好、权威和稀缺这六个方面,探讨了影响力是如何影响人们的。你如果感兴趣也可以去仔细阅读一下这本书。这里我并没有完全套用这六个因素,而是基于我们管理沟通中的实际场景,并结合技术管理者日常可以采用的手段,整理出如下四个维度、八个因素。
|
||||
|
||||
|
||||
|
||||
非职权影响力的四维八因素(果见)
|
||||
|
||||
第一个维度是信任,是关于“人”的。其影响力发挥的逻辑是:“你之所以能影响我,是因为你是 XX,我信任你这个人。”这个维度有两个因素比较有效:
|
||||
|
||||
一、人品和品格。这个看上去挺虚的因素,在人们实际的决策中却起着非常重要的作用。我访谈过几位高级别的管理者,问他们愿意对什么样的下属委以重任,他们基本都会提到“人品”这个因素,人品比较“正”的人他们更愿意信任。所以要想提升自己在这个因素上的影响力,不妨去盘点一下别人经常用什么正向的词来形容你,并进一步地把它们打磨得更加鲜明。一旦对方认同你的人品,就有了很好的信任基础。
|
||||
|
||||
二、历史表现。我经常和新经理们说:“你们当前的影响力,很大程度上来源于你们之前的历史表现,所以,要想之后有更好的影响力,就从现在的事情做起吧!”那么,怎么做呢?去承诺,然后去兑现承诺,即秉承我们常说的“承诺一致性”。这个方法是我最习惯于使用的。我曾两次空降做技术 VP 或 CTO,两次都和 CEO 建立了良好的信任,主要就是靠“承诺一致性”。
|
||||
|
||||
关于这一点,我相信很多技术管理者们都能做到兑现承诺,但是,却只有少数能做到“事前承诺”。比如,和上级约定好一段时间内所要完成的重点工作,并承诺完成。多数管理者会说“我尽量完成”,甚至是不置可否,就着手去推进这些工作了。虽然你的上级知道你在负责,但是他们心里对你能不能搞定并没有底。如果你能多次匹配到上级的预期,信任感也能建起来,但是如果你能事前做出承诺,并且成功兑现承诺的话,上级对你的信任会提升得更加迅速。
|
||||
|
||||
你可能会说:“如果我承诺了,兑现不了怎么办?”
|
||||
|
||||
首先,你不能做很多承诺,而只要去承诺那些你和上级都认为最重要的 1~3 件工作。
|
||||
|
||||
其次,如果中途发生变化,提前做出更合理的调整,并和上级重新明确约定。
|
||||
|
||||
最后,既然是你和上级都认为重要的工作,就全力以赴去确保兑现,尽可能避免上面“其次”中那种情况的发生。
|
||||
|
||||
总之,要通过这个因素去提升影响力,就要确保“承诺一致性”,即,要兑现承诺,而更重要的还是要去做出承诺。这虽然会有些压力,但是无论对事还是对你们的信任关系,都是更有价值的做法。
|
||||
|
||||
第二个维度是专业,是关于“能力”的。其影响力发挥的逻辑是:“你之所以能影响我,是因为我觉得你更专业,你有这个能力。”这个维度的影响力,也可以通过两个因素来提升:
|
||||
|
||||
提升权威度。这个很容易理解,在特定领域专业度较高的人,对于方案往往有更强的话语权。作为管理者,你不可能在各个方面都有很高的专业度,但是需要有一个专业度是显著的,要显著到什么程度呢?这和对方对你的期待有关系,比他的期待高得越多,就越有影响力。但是,现实更常见的情况是,管理者在某技术方面的专业度并不是团队里或行业里最高的,此时,借助你可以借助的权威,让这些权威人士,或是权威人士的说法给你站台,也是可以提高说服力的。
|
||||
|
||||
提高逻辑性。数据准确,论据充分,条理分明,逻辑清晰,都会大大提升你的观点和结论的可信度。如果你想说服别人,你的论述就要有很好的逻辑性,经得起推敲。如果你在表述一个问题的时候,三句两句就被问得一头雾水、不知所措的话,又怎么能够让别人信服呢?虽然逻辑能力也需要长期锻炼,但是相较而言,这是少数可以经过努力在短时间得到提升的影响力因素。
|
||||
|
||||
第三个维度是情绪,是关于“情绪情感”的。其影响力发挥的逻辑是:“你之所以能影响我,是我被你感染和感动了。”这个维度的影响力发挥,也有两个因素可以考虑:
|
||||
|
||||
通过诉诸情怀来感染人。虽然在很多人眼里情怀不能当饭吃,但是在一些吃饱饭的人眼里,情怀很重要。有的时候,对方看到你高远的视角和情怀,就会情不自禁地想帮你一把,甚至还会追随你一起努力。这就是为什么很多创业者会去宣扬自己的情怀和使命。你也可以把你的意图诉诸于你的某个情怀,当然前提是:它是真的。若勉强往情怀上靠反而会让对方反感,最后适得其反。
|
||||
|
||||
通过情绪来感染人。毕竟,人不是纯理性的,否则的话,那些基于“理性人”假设的经济规律早就摸透我们的前世今生了。很多时候,经济学家们之所以无法准确预测经济规律,主要还是因为他们的基本假设不成立,即,人不是纯理性的。即便是诸葛亮那么聪明睿智又小心谨慎的人,不还是在马谡的“愿立军令状”这样的决心和气魄下,委以重任去守街亭了?虽然事败,但马谡在说服影响诸葛亮的决策上,是成功的。所以,在你志在必得的事情上,也不妨拿出你的气魄和勇气来。
|
||||
|
||||
第四个维度是互惠,是关于“心理债务”的。其影响力发挥的逻辑是:“我欠你的,我会想办法还给你。”虽然叫“互惠”,但这个维度的焦点在于“施惠”。由于人们普遍有“还债”心理,所以一旦你首先去支持和帮助别人,那么以后别人也会找机会来回报,这样你的请求就容易被满足了。
|
||||
|
||||
关于这一点的更多论述,如果你感兴趣的话,还请参照《影响力》这本书的第 2 章。在我们日常的管理沟通中,有两个因素可以考虑:
|
||||
|
||||
厘清对方的诉求,去满足对方的诉求,然后再来满足自己的诉求。这就是我们通常意义上说的双赢。在很多临时性合作、一次性合作和对外合作中,这都是合作的基础和前提。而且,当你捕捉到对方在乎和看重的是什么的时候,也就更能说服对方接受你的方案。
|
||||
|
||||
主动提供支持和帮助。很多人都会觉得,主动提供了帮助,如果没有得到显性的回报,就认为自己“亏了”。那么今天我告诉你,即便对方没有显性的回报,你也收获到了对于他的影响力,所以你并没有白白付出。比如,很多管理者在和架构师合作的时候,就可以多帮他们摆平一些目标澄清、资源申请、项目协调、人员管理等方面的“杂事”,慢慢你就会发现,你对他们的影响力变得越来越强。
|
||||
|
||||
综合我们上面讨论的关于发挥影响力的四个维度、八个因素,你就可以梳理自己的影响力了。
|
||||
|
||||
当然,审视自己的影响力大小,都是基于某个假设对象的,如果没有预先明确影响对象,影响力就无从谈起。比如对于一些艺人来说,他们在粉丝眼中是神一般的存在,但是在另一群人眼中,他们的影响力也许趋近于零。所以,无论是对上,还是对下,抑或是对横向的合作者,明确好对象,才能去评判自己的影响力高低,以及哪个维度和因素的影响力更大。
|
||||
|
||||
至此,我们知道了非职权影响力所涵盖的维度,于是,该如何提升自己的影响力也就有章可循了,即,从前面提到的四个维度、八个要素去提升。具体可以参照下表:
|
||||
|
||||
|
||||
|
||||
提升非职权影响力的方法(果见)
|
||||
|
||||
你可能会问,影响力的提升毕竟是一个长期累积的过程,假如我当下就要去说服和影响别人,那该怎么办呢?
|
||||
|
||||
我想说,你个人的影响力的确是需要长期经营的,所以你当下就要发挥影响力的话,就只能基于你当下的影响力水平,因为你无法让影响力立马暴增。但是,也还是有一些影响力是短时间内可以提升的,比如上表中我用红圈圈出来的部分。如果你此时就要发挥影响力去说服和影响别人,不妨在这几个方面下下功夫:
|
||||
|
||||
反复打磨你的思路和逻辑,让你的观点和结论很有说服力;
|
||||
|
||||
如此这般,你也算是尽了全力了。剩下的,就交给老天吧!其实这个“老天”,很大程度上,就是你之前积累的那些固有的影响力,看不到这一点的人,就归结为“天意”了。
|
||||
|
||||
至此,我们就讨论完了关于影响力的内容,它包括职权影响力和非职权影响力两个大类,每个大类又由多个因素构成,相信你对它们已经有了一个整体上的认识。
|
||||
|
||||
现在,我们回到之前遗留的两个问题:
|
||||
|
||||
显然,对于这两个问题来说,你的职权影响力都无从发挥。因为对于上级来说,你的职权影响力是负的;对于横向的合作方来说,你也没有什么职权影响力。所以这两个场景下,我们发挥的都是非职权影响力。
|
||||
|
||||
关于第 1 个问题,对上级的影响力,主要体现在“信任”和“专业”这两个维度上。由于你们已经有了长时间的合作和信任积累,所以着眼于这两个维度来发挥和培养自己的影响力是最合适的。
|
||||
|
||||
关于第 2 个问题,对横向合作方的影响,我认为可以分两种情况来看:
|
||||
|
||||
第一种情况,是你和合作者有共同的上级。那么你就有一个底线,如果非职权影响力不够,你就可以诉诸你们的共同上级对于合作方的职权影响力来解决问题。当然前提是你得先向上影响你们的共同上级。
|
||||
|
||||
第二种情况,是你和合作者没有明显的共同上级。此时,非职权影响力的第四个维度——“互惠”就成为你们合作的核心。当然,也可以看对象情况,考虑使用“情绪”“专业”和“信任”来发挥影响力。
|
||||
|
||||
由此可见,我们通常说的横向沟通,其实可以分为两类截然不同的合作关系,针对这两类合作关系需要采取不同的合作策略。很多管理者不加以区分,所以在横向合作中踩了不少坑。
|
||||
|
||||
好了,关于横向沟通,以及如何盘点和提升影响力的问题,我们就先探讨到这里。这已经是一篇长文了,如果你还有想聊的话题,欢迎给我留言。
|
||||
|
||||
|
||||
|
||||
|
153
专栏/技术管理实战36讲/33向下沟通的常见实例解析.md
Normal file
153
专栏/技术管理实战36讲/33向下沟通的常见实例解析.md
Normal file
@ -0,0 +1,153 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
33 向下沟通的常见实例解析
|
||||
谈到向下沟通,技术管理者们纷纷表示有话要说,也许此时的你,就正带着一堆向下沟通的问题在读这篇文章。
|
||||
|
||||
只要是带团队,在日常的管理工作中,我们就离不开向下沟通这个话题。技术管理者最挑战的管理主题中,向下沟通也名列前茅,仅次于向上沟通、员工激励和团队凝聚力建设。你是否会好奇,显然我们和下级的沟通比和上级更频繁,为什么挑战反而比向上沟通要小呢?如果你还记得上一篇文章中我们探讨过的影响力问题,就很容易理解了:向下沟通,我们除了可以依靠非职权影响力之外,职权影响力也在发挥作用,因此,很多向下沟通的挑战就被职权影响力化解了。
|
||||
|
||||
但是由于向下沟通场景的基数太大,各种各样的下级带来的各种各样的问题也就涌现出来了。那么,向下沟通的问题有哪些特点呢?我在归纳了一百多个案例之后发现,如下四类问题特别集中。
|
||||
|
||||
第一类,也是反馈最多的一类,是询问“如何批评员工”。这类常见的说法有:
|
||||
|
||||
“A 的项目总是 delay,每次沟通她总是态度积极,表示一定改正,但行动上却还是老样子。我该怎么批评她呢?”
|
||||
|
||||
“B 的工作做得很粗糙,不追求精益求精,只是做完而不是做好。我要怎么批评他,才能让他改正缺点,又不打击他的干劲儿呢?”
|
||||
|
||||
“C 的周报发的特别水,请假也不提前打招呼,我问她什么原因,虽然她的解释有一定道理,但是我还是想让她改掉这些问题,有什么办法吗?”
|
||||
|
||||
“公司实施弹性工作制,D 本来 10 点就到公司了,但发现其他人都没有来,觉得不公平,以后他就故意来晚。结果造成部门的工作时间整体推迟,但是这又很难批评他一个人,你有什么主意吗?”
|
||||
|
||||
“E 不以解决问题为导向,发现问题后不主动跟进解决,总是推托说这不是他的问题。我平时也会跟他说要多担当,但是没有效果。该怎么批评他,让他改正缺点呢?”
|
||||
|
||||
第二类,沟通不顺畅。常见的说法有:
|
||||
|
||||
“在沟通的时候 A 特别沉默,什么都不愿意反馈,问一句答半句,每次沟通都是草草了事,我也发愁后续怎么和她沟通。”
|
||||
|
||||
“和 B 总聊不到一个频道上,我聊目标,他聊困难,我聊进展,他聊原因……毫无默契可言。”
|
||||
|
||||
“我就从来不知道 C 在想什么,她常常口头上说的是一回事,其实内心想的是另一回事,捉摸不透,无法知道她的真实诉求。”
|
||||
|
||||
“D 之前经常会把做出来的成果给我看,我每次都说了‘很棒’啊,可为啥看她的反应还是情绪不高,挺闷闷不乐啊?”
|
||||
|
||||
第三类,和“牛人”下属之间的较量。常见的说法有:
|
||||
|
||||
“我们团队的 A 技术架构能力很强,独立工作能力也很好,我很难对他的发展和工作给出建议和帮助,不知道怎么带他。”
|
||||
|
||||
“我和团队里的架构师 B,常常在一些技术决策上发生争执,有点合作不下去了。”
|
||||
|
||||
“我团队的 C 成长很快,感觉他越来越不服我,我是不是得把技术捡起来了?”
|
||||
|
||||
第四类,不知如何应对一些“刺头”员工。常见的说法有:
|
||||
|
||||
“A 总是越级汇报,我非常反感,但是又拿他没办法,他特别会讨好我的上级。”
|
||||
|
||||
“B 总是挑活,还很固执,怎么辅导也改不了,真是头疼。”
|
||||
|
||||
“C 总是暗示我给他升职加薪,可是我觉得他能力还不够,怎么跟他沟通才能不打击他的积极性呢?”
|
||||
|
||||
“D 特别情绪化,动不动就跟人吵架,经常在会上乱怼一通,大家都不愿和他共事,可是他技术能力挺强的,怎么辅导他呢?”
|
||||
|
||||
怎么样,上面这四类问题,是不是你也关心呢?
|
||||
|
||||
不过,在正式探讨这些问题之前,我需要首先澄清一个理念:通过上面大家反馈的问题你会发现,虽然大家都认为这是一个“向下沟通”的问题,但是如果我们脱开管理逻辑,单纯去探讨如何“沟通”,就会掉入“舍本逐末”的陷阱,导致在和员工沟通的时候很苍白无力、收效甚微。
|
||||
|
||||
因此,我们探讨管理沟通问题的时候,需要有“管理逻辑”和“沟通方法”两个层面的视角。所谓“管理逻辑”,就是首先弄清楚这是个什么管理问题,并从管理角度来看完整的解决方案应该是什么样的,然后再来看“沟通”该如何来实施。两者不能割裂开,甚至有的管理者出现了管理逻辑和沟通思路相背离的情况,就更加不应该了。
|
||||
|
||||
这听上去会不会比较虚?那我们下面举例来说明一下。
|
||||
|
||||
例 1:很多管理者会咨询我,“如何和低绩效员工做绩效沟通?”这显然没有意识到更重要的是绩效管理本身,沟通只是绩效管理的一环而已。所以要想解决低绩效员工的绩效沟通问题,首先要从绩效管理入手,然后再来看如何实施沟通。也正是因为这个原因,我并没有把绩效沟通的话题,放在管理沟通这一章来讨论。
|
||||
|
||||
例 2:很多管理者会问,“员工积极性不高,如何和他沟通呢?”你不难发现,沟通效果好的话,的确可以对员工起到激励的作用,但是这整体上是一个员工激励的问题,沟通是不是最有效的手段呢?这需要我们从管理视角和沟通视角两个层面来思考。
|
||||
|
||||
好了,相信你已经明白我的意思了,就是不要把管理沟通问题单纯看成是沟通问题,其实很大的比重是在管理逻辑上,需要我们从“角色认知”和“管理规划”“团队建设”“任务管理”(还记得我们的“三明治”管理框架吗)的管理方法论上去思考整体解决方案。
|
||||
|
||||
接下来,我们就一起来分析一下常见的这些“向下沟通”的问题。
|
||||
|
||||
对于第一类问题,关于“如何批评员工”。
|
||||
|
||||
这类问题最为普遍,为什么呢?因为对于一个我们不认可的行为,第一反应就是认定“对方不应该”,于是,我们就要通过“批评”这样的手段来“纠正他的错误”。所以你会发现,批评背后的真实意图是“促其改变”。而很多管理者并没有认识到这一点,因为他们所采取的手段和真正的意图直接产生了矛盾,不但不能促使对方改变,甚至还封闭了对方改变的道路。比如,一旦违背了如下三个批评的原则,“促其改变”的效果就很难达到:
|
||||
|
||||
人是 OK 的原则。即,对事不对人。批评事,不要打击人,更不能给人贴标签。
|
||||
|
||||
具体性原则。指出具体哪里做的不好,让对方容易认同。
|
||||
|
||||
面向未来的原则。体现负面的暂时性和过去时,并提供改变的“出口”。
|
||||
|
||||
那么,具体应该怎么批评呢?在教练领域有一个 AID 批评法,大体上也遵循了上述原则,具体分为如下图中的三步:
|
||||
|
||||
|
||||
|
||||
AID 批评三步法(发展性反馈)
|
||||
|
||||
以上呢,是和大家探讨如何批评一个员工。但我还想问的是,在一个不符合我们期望的事件发生时,批评对方真的是我们想要的吗?
|
||||
|
||||
比如前面案例中的一个问题,“我团队的某个员工越过我和我的上级沟通”,那我就很想知道,你真正介意的是什么呢?如果你只是希望自己和他们两个的信息是一致的,那只要约定一个同步机制就好了,你需要批评下级员工吗?所以你看,当你意图从“你不想让员工跨级汇报”变成了“我想让我们三个人之间的信息保持同步”后,批评员工就不再是最好的选择了。
|
||||
|
||||
所以,当你遇到一些不符合期待的问题时,建议先从“我不要……”这种意图中走出来,问问自己“我要什么”。然后再来审视采取什么手段是最合适的,这就叫意图转换。具体可以参照下面的示意图。
|
||||
|
||||
|
||||
|
||||
意图转换流程(果见)
|
||||
|
||||
好了,我们要如何应对需要“批评”的员工呢?归结为一句话就是:先转换下意图看看是否需要批评,如果批评依然是最好的手段,那就要用 AID 批评法,为员工改变提供出口。
|
||||
|
||||
对于第二类问题,关于和下级员工沟通不顺畅。
|
||||
|
||||
这就需要用一些工具和技巧来辅助沟通了,我针对这些场景介绍几个工具供参考:
|
||||
|
||||
1、对于内向沉默的员工,可以使用下图的“积极引导四步法”,引导员工打开话匣子,主要话题不必局限于工作,跟员工建立起沟通关系和沟通通道,是首要任务。
|
||||
|
||||
|
||||
|
||||
积极引导四步法(果见)
|
||||
|
||||
2、对于总聊不到一个频道上的员工,可以使用我们在第 29 篇文章中介绍的“沟通层次图”,从事实、感受(判断)和意图三个层面来和对方进行频道对齐。
|
||||
|
||||
3、对于捉摸不透的员工,也可以使用“沟通层次图”或“3F 倾听”来分辨对方表达的内容,为了避免误会,可以做一些回放和复述,使用类似下面的话术:“你是不是这个意思?”“你看我的理解对不对?”这样就可以大幅度减少沟通偏差了。
|
||||
|
||||
4、对于如何给员工的表现进行反馈,我推荐使用“主动积极式反馈”,如果你感兴趣的话,可以去网上搜索一下这个工具,也很容易理解。
|
||||
|
||||
其实,沟通的工具很多,大多都是理解起来不难,但掌握起来并不易,如果要想达到“手中无剑、心中有剑”的境界,就更是需要长期的刻意练习。
|
||||
|
||||
对于第三类问题,关于如何应对“牛人”下属。
|
||||
|
||||
从称谓就可以看出,“牛人”下属肯定属于做事很给力的那类员工,常常是专业能力很强的技术高工和架构师。作为管理者,你如果还在和自己团队的架构师在技术上一较高下,甚至是“你死我活”地争执,那么这就不是一个沟通问题,而是一个典型的管理问题,确切地说,是管理角色认知问题。
|
||||
|
||||
你作为管理者,就要很好地认清自己的角色,认识到自己是团队的带路人和负责人,而不是要和架构师站在一个层次上去争高低输赢的。在这方面,我们得向汉高祖刘邦学习一下,他是靠什么把各个方面的“牛人”拢到一起的呢?关于如何和“牛人”技术高工相处,我的心得如下:
|
||||
|
||||
|
||||
|
||||
高工管理四个要点(果见)
|
||||
|
||||
从这四个方面来达成和“牛人”员工的良好协同。
|
||||
|
||||
对于第四类问题,关于如何应对一些“刺头”员工。
|
||||
|
||||
首先我们得澄清一下,什么叫“刺头”员工呢?我们约定一下:那些需要你付出非常多的时间和精力去管理的员工,叫做“刺头”,也就是管理成本很高的员工。这么一说,相信你团队中某些员工就会浮现在你的眼前了吧?你通常是怎么应对的呢?
|
||||
|
||||
既然我们是从管理成本角度来看待这类员工,那我们就需要首先从投入产出比来评估一下,这个员工是否值得你耗费那么多管理成本。毕竟你作为一个团队的 leader,是需要对整个团队的发展和业绩负责的,你的角色需要你把精力投入到那些对团队和业绩最为有效的地方,这无关情感和道德。
|
||||
|
||||
那么,如何判断值得不值得呢?可以从团队和做事两个方面来看,具体参考下面的“刺头”员工价值评估四象限:
|
||||
|
||||
|
||||
|
||||
“刺头”员工价值评估四象限(果见)
|
||||
|
||||
评价出来之后,需要淘汰的,很明确;如果有需要改变的怎么办呢?关于如何促使一个人做出改变,美国学者理查德·贝克哈德的改变公式,可以给我们一些指导:
|
||||
|
||||
|
||||
|
||||
理查德·贝克哈德的改变公式
|
||||
|
||||
也就是说,你要改变一人,可以从他的“痛点”“痒点”出发,并和他一起制定“迈出第一步”的行动计划,从而去帮他克服掉改变的阻力。
|
||||
|
||||
好了,至此,向下沟通中最常见的四类问题,我都做了一个回应,相信你对向下管理这个主题会有一个整体的了解。
|
||||
|
||||
考虑到文章篇幅问题,我并没有把每一个工具、步骤及其背后的逻辑都展开论述。如果你对哪一部分特别感兴趣,欢迎给我留言,或者我们也可以再找机会深入探讨。
|
||||
|
||||
|
||||
|
||||
|
121
专栏/技术管理实战36讲/34管理沟通上有哪些常见的坑儿呢?.md
Normal file
121
专栏/技术管理实战36讲/34管理沟通上有哪些常见的坑儿呢?.md
Normal file
@ -0,0 +1,121 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
34 管理沟通上有哪些常见的坑儿呢?
|
||||
本文是关于管理沟通问题的最后一篇文章,前面的六篇文章,都是在探讨如何帮管理者们应对管理沟通的问题和挑战的。这篇文章,我想聊聊技术管理者,尤其是新管理者们,常见的五类管理沟通误区。这些常见的表现和行为都来自于真实的管理场景中,可能是你,也可能是你的下级管理者,甚至是你的上级管理者。下面,我们一起来“照照镜子”。
|
||||
|
||||
第一类误区,常见的说法有:
|
||||
|
||||
在项目攻坚初期,有的技术管理者会这样说:“需求还没有出来,为什么我们团队要陪产品团队一起 996?”
|
||||
|
||||
当上级要求运营任务的时候,有些管理者会这样说:“为什么要我们团队傻傻地去点赞?这个又不在我们团队的职责范围内。”
|
||||
|
||||
在评审产品设计的时候,有些技术管理者会这样说:“怎么会有这么二的设计,一点儿逻辑都没有!”
|
||||
|
||||
在确认产品功能和效果的时候,有的产品团队管理者会这样说:“怎么研发老是自作主张,看不懂需求文档吗!”
|
||||
|
||||
上面这四个说法有什么共同点呢?
|
||||
|
||||
你不难发现,这类说法如果出自一名工程师或者一线产品经理之口,他们只是对于自己不能理解的做法,给出了基于自己角色的观点和态度,倒也无可厚非。但是如果是出自一位管理者之口,无论是技术团队的管理者,还是产品团队的管理者,其“视角”就未免有些低了。这类说法背后的逻辑是:这不是我团队的事儿,问题都是别人团队的。所以我把它们归纳为沟通视角问题:沟通仅从自己出发,对管理者的角色和视角认知不够。
|
||||
|
||||
对此,我只想阐述一个简单的逻辑:一线员工是用工作量来评估价值的,他们只要做出了自己该做的,就是有价值的;而管理者是用团队业绩来评估价值的,即便不是管理者个人的原因,只要结果是团队不出业绩,那么管理者的价值就很难体现。而且,如果“不幸”其团队成员都很能干的话,就更加凸显出管理者的失败。
|
||||
|
||||
所以,管理者要做出好的业绩,就需要站高一层,站在自己上级的视角来和各个团队协同,以收获共同期待的成果。并且大部分时候,帮合作团队一起做好工作,也是为了自己的业绩,你并不会吃亏。
|
||||
|
||||
第二类误区,常见的说法有:
|
||||
|
||||
上级问:“按照计划进度不是要到 60% 了吗,怎么才到 40% 啊?”有的管理者这样回答:“这也不能怪我啊,产品变更需求了!”
|
||||
|
||||
上级问:“约定好的流程为什么没有走呢?”有的管理者这样回应:“为啥其他人不走流程你就不说,我已经很认真了啊,流程有这么多问题,我工作又这么紧张……”
|
||||
|
||||
合作者说:“这里有个问题,帮忙看看怎么回事吧。”有的管理者这样回应:“这不可能,肯定是你看错了”,或者说:“只能做成这样子,我也没办法。”
|
||||
|
||||
合作者问:“这个 BUG 有多大影响?”有的管理者这样回应:“我估不出来,你找别人吧!”
|
||||
|
||||
对于以上四个管理者的回应,如果你是他的上级或合作者,你会是什么感受呢?
|
||||
|
||||
我估计你会有如下两个直接反应:
|
||||
|
||||
疑惑和僵住:“我也没说啥啊,咋就毛了呢?这话茬没法接下去了啊……”
|
||||
|
||||
远离和放弃:“这人说不得啊,没法交流,以后少打交道吧。”
|
||||
|
||||
无论是哪个反应,对于这位管理者来说,都是不愿看到的消极负向的结果。由于这类管理者总是以为对方在针对自己,过于敏感,所以我把这类问题归纳为沟通姿态问题:总是在防卫,随时准备战斗。
|
||||
|
||||
对此,我想说,防卫姿态对于管理者做好工作不会有正向价值,长此以往,就等于关闭了别人提供帮助的大门,任其自生自灭,这显然是个双输的结果。所以,工作中最好还是以做事为主,少考虑一些个人感受。如果就事论事地去沟通问题,反而会赢得更多合作者的尊重。
|
||||
|
||||
第三类误区,常见的说法有:
|
||||
|
||||
管理者这样对下属说:“你怎么这么不靠谱,这么简单的事儿你都搞不定!”
|
||||
|
||||
对下属相似的说法还有:“你能不能务实一些?你能不能踏实一些?你能不能努力一些?你能不能用点脑子……”
|
||||
|
||||
管理者这样抱怨合作方:“太脑残了,就没见过你这样的!”
|
||||
|
||||
管理者这样对合作的产品经理或设计师说:“你到底懂不懂怎么做产品,你根本就不懂设计。”
|
||||
|
||||
对于以上四类说法,或许有两种可能:
|
||||
|
||||
只不过,无论是哪种情况,这样的说法都换不来下属和合作方的改变。
|
||||
|
||||
原因在于,这是一种“对人不对事”的沟通,你已经给对方贴上了负面的“标签”,而一旦给人贴上了标签,对方也就放弃了改变自己的意愿,失去了改变自己的动力。因为“反正在你心目中已经是这样的一个人了,何必徒劳无功呢!你爱咋滴咋滴,实在不行我走人”。所以,我把这类问题归纳为沟通方式问题:先给人贴标签,对人不对事。
|
||||
|
||||
作为一个管理者,如果没有注意到自己这个沟通方式的弊端的话,你将会承担这样的损失:
|
||||
|
||||
别人成了你眼中的“屡教不改”,你看不到别人的改变。
|
||||
|
||||
你在别人心中失去了管理者的威信,大家会觉得你没有管理者的胸襟和风范。
|
||||
|
||||
一旦意识到问题所在,解决起来倒也简单:学会管理自己的情绪,就事论事地来讨论事情。前面几篇文章中探讨的情绪管理和沟通工具的内容,都对此会有帮助。
|
||||
|
||||
第四类误区,常见的情形有:
|
||||
|
||||
你发了一条消息石沉大海……
|
||||
|
||||
你发了一封邮件石沉大海……
|
||||
|
||||
你安排了一项任务石沉大海……
|
||||
|
||||
然后开始扯皮:
|
||||
|
||||
“我说了啊;我发了啊;我安排了啊;我通知了啊……”
|
||||
|
||||
“我没看到;我没收到;我没注意;我不会做;我觉得没那么重要;我觉得没那么急;我没时间;我看不懂;不该是我干……”
|
||||
|
||||
上述这类沟通问题如果还出现在技术管理者身上,我表示非常遗憾。问个技术人才能懂的问题:你做模块间通信都知道用 TCP/IP 协议,要完成三次握手,为啥你做管理所建立的沟通机制,就总用 UDP 的方式呢?
|
||||
|
||||
显然,这类问题就出在没有形成良好的“沟通闭环”意识,认为消息和邮件发出去了,接收到的人就应该都及时看到;任务安排出去了,别人就得无失真地接收到。因此,我把这类问题归纳为沟通意识问题:沟通没有形成闭环。
|
||||
|
||||
既然是意识问题,应对这类问题的办法也是建立觉察,意识到这一点:不能默认对方一定能收到,而且不能默认对方理解的和你想的是一致的。所以,对于你关心的问题,一定要去确认清楚,跟进到底,形成沟通闭环。在这个问题上,我们之前文章中介绍的“回放话术”可以帮你把确认工作做得更加充分。
|
||||
|
||||
第五类误区,常见的情形有:
|
||||
|
||||
关于上面这四类说法,即便你不是这样的管理者,想必你也肯定和这样的管理者打过交道吧?他们共同的特点就是发泄抱怨,并没有给出应对的建议和解决方案。所以我把这类问题归纳为沟通初衷问题:只给抱怨不给建议。
|
||||
|
||||
作为管理者我们需要清楚一点,的确会有很多事情是我们掌控之外的,其中不乏不合理或不完善的。对于这样的情况,发泄抱怨则意味着我们内心深处已经对此无能无力了。而实际上,我们也许并不需要完美地解决这个问题,而只需要把一个 40 分的状态改善到 60 分就行了,或者即便没有改善到 60 分,我们也把事情往好的方向上推进了一点点,这也是我们的价值。而抱怨除了把负面情绪感染给团队之外,收获不到任何正向的价值。
|
||||
|
||||
应对这类问题,需要做的是意图转换,如前面第 33 篇文中介绍的,从“我不要……”转换到“我想要……”,然后看看有哪些事情可以做。比如对于上述四个问题,我们可以这样问自己:
|
||||
|
||||
“这个规定太不合理了,没法遵守!”——那么,怎么样就合理了?
|
||||
|
||||
“我们在指定日期肯定做不完,没戏!”——那么,什么条件满足之后,就能做完呢?或者,认为什么时候能做完?
|
||||
|
||||
“这个设计很不合理,完全不考虑用户体验!”——那么,怎么样会合理一些呢?
|
||||
|
||||
“团队的氛围太差了,郁闷!”——那么,怎么做氛围会变好一点点呢?
|
||||
|
||||
通过问自己这些问题,相信你会有“意外”的发现,而正是这些“意外”的发现,才是你的创造力、价值以及管理能力的体现。
|
||||
|
||||
好了,关于管理沟通的误区,到这里,我们一共探讨了五类:
|
||||
|
||||
视角问题:沟通仅从自己出发,对管理者的角色和视角认知不够。
|
||||
|
||||
这五类问题,是管理工作中最容易遇到的。除此之外,我相信你还会找出很多其他管理沟通上的问题,这也正是沟通复杂的地方。不过,就上面这五类最集中的问题,如果我们“照照镜子”的话,肯定是能看到自己的一些“轮廓”的,不是吗?
|
||||
|
||||
至此,关于管理沟通的内容,我们就探讨完了。沟通是个大话题,市面上沟通培训的课程和知识也非常多。在这个专栏中,我主要从技术管理者的角度和实际工作场景出发,先后讲解了管理沟通框架、沟通层次图、情绪管理,以及向上、横向和向下三大沟通场景,今天又介绍了常见的一些沟通误区。希望这些内容可以为技术管理岗位上的你带来一些启发和帮助。
|
||||
|
||||
|
||||
|
||||
|
143
专栏/技术管理实战36讲/35从空降谈管理方法论的积累.md
Normal file
143
专栏/技术管理实战36讲/35从空降谈管理方法论的积累.md
Normal file
@ -0,0 +1,143 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
35 从空降谈管理方法论的积累
|
||||
随着管理经验的不断积累,你需要不断提炼出自己的管理方法论。随着你掌握了越来越多、越来越行之有效的方法论,你管理能力的可迁移性就越来越好,也就意味着你越来越能胜任不同规模、不同业务特点的团队管理。无论是“自用”还是“带人”,都离不开方法论的积累。因此,不少公司在评估管理晋升的时候,都会把管理方法论作为一个维度来考察。
|
||||
|
||||
今天,我们就来探讨一下管理方法论的积累问题。
|
||||
|
||||
管理方法论,顾名思义,就是关于“管理”的方法论。可是管理这么大的话题,方法论的积累要从哪里着手呢?
|
||||
|
||||
我们不妨先来看一个管理方法论运用最为集中的场景——空降。如果你还记得我们的“马车模型”的话,那空降时你对“车”“马”“路”和“方向”都还不熟悉,当然是你运用自己管理方法论的重要时刻;而且,很多专栏读者也咨询我这个问题,所以我们就这个机会一起来聊一聊。
|
||||
|
||||
对于很多新管理者来说,也许还没有经历过空降,而对于很多资深管理者来说,却不可避免地要经历空降。即使没有空降到一个新的公司,也可能会空降到一个新的团队。今天,我们就选择最具挑战的空降场景,即空降到一个全新的团队,同时面临全新的上级、下级、平级合作者和新的业务。此时,如果这个空降的管理者就是你,你会首先做哪几件事呢?
|
||||
|
||||
同样的问题,我曾经询问过我课堂上的管理者们,大体的答复如下:
|
||||
|
||||
“和几位核心下属管理者沟通,了解他们的情况、看法和期待。”
|
||||
|
||||
“和上级沟通,了解一下团队的整体情况,以及团队的职责。”
|
||||
|
||||
“和之前负责这个团队的管理者了解团队情况,问问有没有特别需要注意的地方。”
|
||||
|
||||
“和团队每个人都聊一遍,跟大家建立联系。”
|
||||
|
||||
“先评估团队的稳定性,稳定团队是首要的。”
|
||||
|
||||
“先看看手头上有哪些重要的工作是要确保完成的。”
|
||||
|
||||
……
|
||||
|
||||
你会发现,大家的说法不一而同,不同的管理者,关注的重点也是不同的,每个人都从自己的视角和经验给出了自己的建议。我充分相信,大家都做出了自己认为的最好选择,我无意去评判谁的更好,因为管理问题不是看好坏对错,而是看是否合适、是否有效的,而是否有效,只有当事人清楚。只是在我看起来,大家这么快就聚焦到一些“点”上,未免缺少了全局感和框架性。
|
||||
|
||||
要是我的话,我会怎么回答呢?
|
||||
|
||||
我有过两次较为“成功”的空降做 CTO 和技术 VP 的经历。这里的“成功”,并不是带着团队成功上市走上人生巅峰,仅仅是就“空降”本身而言还算成功。因为满足了这样三个标准:
|
||||
|
||||
和新同事建立起了良好的信任和协作关系,尤其是和直接上级及重要下级。
|
||||
|
||||
只要你愿意,你可以在该公司的该职位上持续做下去,上级和公司是欢迎的。
|
||||
|
||||
那么,是哪些做法帮我顺利完成空降过程了呢?我总结起来,最核心的是如下三点:
|
||||
|
||||
第一点,诚意正心。即,准备好自己的心态。我会问自己的初心:“你到底想要的是什么?你能为上级、下级和公司带来哪些价值呢?”通过问自己这个问题,我会秉持一种帮助公司、帮助 CEO 和下属的初衷,把我们的利益全部统一起来,以至于从一开始就不担心上级不信任、下级不服气以及同级排挤的问题。因为,每个人都不会拒绝你给他带来支持和帮助的。
|
||||
|
||||
遇到冲突时,跳出自己的角色来判断是非对错,通过审视初心来做决策,很容易让自己充满力量,以至于两家 CEO 和联合创始人都曾评价我“人很正”。当然,这无关管理方法论,更多的是对职场法则的认知和理解,也正是这个最基础的哲学,给予我应对冲突的基本逻辑判断。
|
||||
|
||||
第二点,对齐期待。我们首先要明白这样一个事实:虽然你进入一家新公司或一个新团队是以某个职位进去的,诸如 CTO、技术 VP、技术总监、技术经理等,但是你得清楚,这只是你的头衔,并不是你的工作“角色”。常常有跳槽的管理者问我“技术总监都做哪些事儿”之类的问题,这显然是混淆了头衔和角色。因为即使是同一个头衔,在不同公司所需要承担的角色可能是千差万别的,所以,不要指望按照头衔去筹划自己的工作,就可以满足上级和公司的期待。
|
||||
|
||||
那么,如何厘清自己的“角色”呢?我的回答是:和你的直接上级去约定(如果你的直接上级对你有充分的管理权限的话)。比如,我每次空降的时候,都会问未来上级一个问题:“长期我们很难约定,仅就我入职后的前三个月或前六个月,你觉得我做好哪三件事,你会对我的工作比较满意?”
|
||||
|
||||
如果对方都没有想过这个问题,你不难发现,对方聘请你的意图是不清晰的,只是觉得应该有一个技术管理者而已。如此,未来合作关系崩掉的可能性会比较大。
|
||||
|
||||
如果对方明确地告诉了对你的预期,那你们就相当于对入职初期的三个月到半年的工作达成了一个清晰的“工作协议”。还记得我在[第 32 篇文章]中提到的“承诺一致性”吗?这个“工作协议”,就是你们快速建立信任的前提。
|
||||
|
||||
如此以来,你和上级对于你的“角色认知”就明确了,这是开展管理工作的前提。
|
||||
|
||||
所以你看,你的角色是由上级和公司对你的具体期待决定的,而不是你的头衔。如果你说话的口吻是“技术总监该干啥,不该干啥……”,就掉入了头衔的误区,而忽略了对角色的厘清。
|
||||
|
||||
第三点,兑现承诺。承诺并兑现,是快速获取上级信任的有效途径。既然前面我们已经和上级约定好了“工作协议”,那么接下来要靠什么来兑现承诺呢?对于技术管理者来说,显然是靠管理价值的体现,所以首先要做这几件事:
|
||||
|
||||
1、和重要相关方建立合作关系,也就是把沟通通道先建起来。比如直接上级、核心下级、重要合作平级等。如果说我们前面搞定的角色认知问题,是管理的前提;那么现在搞定的沟通问题,则是管理工作的载体。而建立沟通通道,则又是沟通的前提。你也许会说,“这么简单的道理,还需要强调吗?”而事实上,就在这个简单的点上,管理者容易如下出现两个问题:
|
||||
|
||||
凭感觉。没有系统盘点关键的沟通通道,凭直觉和感觉建立合作关系。
|
||||
|
||||
被忽略。有的管理者反馈:“入职两周了,合作方有事还是找之前的管理者沟通……”这究其原因,就是没有对外建立沟通通道。
|
||||
|
||||
2、盘点团队当前工作的轻重缓急。这是为了保持工作推进的平滑稳定,不能因为你的到来耽误了重要工作的正常进展。至于长期来看是不是最合理的安排,可以后续通过管理规划来重新审视。
|
||||
|
||||
3、盘点团队人员情况。还记得“团建六要素”吗?——能力、意愿、分工、协作、梯队和文化,可以从这六个方面去审视团队现状,为管理规划提供信息。
|
||||
|
||||
4、管理规划。随着你对业务情况、团队人员的逐渐了解,你可以逐步做出自己的管理规划了,即未来三个月或半年,你希望把团队带成什么样子,做出什么业绩。
|
||||
|
||||
至于还有没有其他事情需要立即着手呢?就需要根据你的实际情况来看了,但上面所阐述的几个方面是必不可少的。
|
||||
|
||||
好了,上面就是我空降经历的一些经验和观点,经过两次亲身验证都效果不错。在我看来,进入一个全新环境中,没有什么比对齐期待和兑现承诺更加有效的建立信任的方式了。而这两者之中,对齐期待是更需要引起注意的,因为大部分管理者都能交付出业绩,但却未必是上级最想要的,从而产生分歧和争执。希望我的这些经验会给你的“空降”带来启发。
|
||||
|
||||
话说,通过上面对空降问题的阐述,你发现什么规律了吗?抛开“诚意正心”的心态不说,我们把前面要做的几件重要的事情开列如下:
|
||||
|
||||
确保当下的要事,梳理优先级。——这一条属于任务管理,即“做事”。
|
||||
|
||||
盘点和熟悉当前的团队。——这一条属于团队建设,即“带人”。
|
||||
|
||||
规划未来的管理愿景。——这一条属于管理规划,即“看方向”。
|
||||
|
||||
是不是已经很明显了?没错,这就是我们的“管理三明治”——我们在[第 8 篇文章]中介绍的管理框架。也就是说,对于管理者最为挑战的“空降”场景,也不外乎从这五个部分来思考管理工作该如何着手。至少从这个框架出发,总比凭感觉和经验要系统些,不是吗?
|
||||
|
||||
|
||||
|
||||
当然,如果你觉得“管理三明治”太粗略了,不够细致的话,那你还记得我们的“管理全景图”吗?你也可以按照其展示的各个要素来思考。细心的话,你会发现我在管理规划、团队建设、任务管理这三个模块的 13 个要素外围都有留白,我的用意就是希望你在自己的实际管理工作中,也能提炼出你自己的心得体会和方法论,并给它们起个名字放入这些空白的地方,从而形成属于你自己的“管理全景图”。
|
||||
|
||||
|
||||
|
||||
在后面的文章中,我们又对“管理沟通”进行了探讨,于是,我们进一步把管理沟通扩展开来,就得到了下面这个沟通扩展版的“管理全景图”:
|
||||
|
||||
|
||||
|
||||
随着扩展的增加,图也变得越来越复杂,所以,最好把“管理三明治”“管理全景图”和“沟通扩展版管理全景图”结合起来使用,这样就可以由粗到细,从浅入深了。
|
||||
|
||||
那么,现在我们就可以回答文章开头提到的问题了:到底就管理的哪些问题积累方法论呢?你不妨从我们的“管理全景图”各个要素入手,根据实际工作场景有意识地积累:
|
||||
|
||||
职能,关于如何澄清团队职能定位——回答团队核心价值的方法论
|
||||
|
||||
目标,关于目标设定和目标管理的方法论
|
||||
|
||||
团队,关于团队规划的方法论
|
||||
|
||||
路径,关于路径选择和成本预算的方法论
|
||||
|
||||
能力,关于如何培养员工工作能力的方法论
|
||||
|
||||
激励,关于如何提升员工工作意愿和积极性的方法论
|
||||
|
||||
分工,关于如何做团队分工和组织架构设计的方法论
|
||||
|
||||
协作,关于如何提升团队凝聚力和默契的方法论
|
||||
|
||||
梯队,关于如何进行梯队建设的方法论
|
||||
|
||||
文化,关于如何打造团队文化价值观的方法论
|
||||
|
||||
轻重缓急,关于如何排优先级的方法论
|
||||
|
||||
有效执行,关于如何做项目管理或项目执行的方法论
|
||||
|
||||
流程机制,关于如何通过流程机制来提升工作质量和效率的方法论
|
||||
|
||||
目的,关于如何明确沟通初衷和目的的方法论
|
||||
|
||||
内容,关于如何确保信息有效传递的方法论
|
||||
|
||||
通道,关于如何建立和增进沟通关系的方法论
|
||||
|
||||
职权影响力,关于不断理解职能影响力的方法论
|
||||
|
||||
非职权影响力,关于提升和运用职权之外的影响力的方法论
|
||||
|
||||
好了,我相信,从这五大方面、18 个要素去按图索骥地、系统地积累自己的方法论,假以时日,你会成为一个既有深度又有广度,既有框架又有方法,既有理论又有实操,既能“自用”又能“带人”的资深管理者。
|
||||
|
||||
|
||||
|
||||
|
117
专栏/技术管理实战36讲/36走出自己的管理之路.md
Normal file
117
专栏/技术管理实战36讲/36走出自己的管理之路.md
Normal file
@ -0,0 +1,117 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
36 走出自己的管理之路
|
||||
我曾设想过很多次,在写本专栏最后一篇文章时,我应该抓住这个最后的机会聊点什么,以及你可能会希望听点什么。
|
||||
|
||||
关于管理的框架、方法、技巧和工具我们前面都进行了探讨,虽然不能覆盖你所有的管理困惑和问题,但至少已经有了一个切入点和应对思路,不至于无从下手。倒是有另外一个问题,是我一直在思索的——做管理对于你,对于我,对于我们每一位技术职场人,到底意味着什么呢?
|
||||
|
||||
你是否还记得在[《开篇词》]中我提到的一个统计结论呢——大约只有 10%~20% 的技术管理者是有明确的管理诉求的,而剩下的 80%,在开始的时候都没有想过要做管理,至少,没有想好是否要做管理。于是,“到底要不要做管理”这个问题长期困扰着他们,动辄持续好几年,一直要到最终想明白自己要什么,抑或是最终到了没有其他选择时,也便放弃了挣扎和纠结,接受既成的现实。
|
||||
|
||||
生活就是这样,如果你不主动去争取你想要的,你就不得不接受一些你不想要的。因此,主动规划自己的管理之路,让我们对未来的发展有更多的掌控感,是很有必要的。
|
||||
|
||||
我不太清楚你是依据什么去判断自己要不要做管理的,但常见的决策依据有下面几类:
|
||||
|
||||
个人发展。认为做管理符合自己的职业发展规划,这类人是少数。
|
||||
|
||||
看好回报。认为做管理可以为自己带来更可观的回报。
|
||||
|
||||
兴趣爱好。喜欢和人打交道,不喜欢和机器打交道。
|
||||
|
||||
社会认同。在家人、朋友等周围人的眼中,做管理尤其是晋升到高管,意味着成功。
|
||||
|
||||
被迫选择。觉得做纯技术不是长久之计,而管理就是技术之外的不二选择。
|
||||
|
||||
被迫接受。上级要求带团队,自己不能辜负公司的信任和期待。
|
||||
|
||||
……
|
||||
|
||||
我想说的是,无论是主动也好,被动也罢;无论是出于使命、兴趣也好,抑或是欲望、压力也罢,只要是在职场中,就有一个基本法则在发挥作用,那就是“价值兑现”,即,你能收获多少回馈,取决于你能输出多少价值。这里的回馈不仅是指物质回馈,还包括成长感、成就感、幸福感等精神回馈。所以,无论是什么初衷,以及选择了什么样的职业道路,最终都会落在一个问题上:“我能否最大化地输出自己的价值?”
|
||||
|
||||
那么,如何才能让自己的价值输出最大化呢?这里我提供两个视角:
|
||||
|
||||
所谓当下视角,就是希望在当下或短期内取得价值输出的最大化。而在这个时刻或者短期之内,你服务的“客户”是明确而具体的,所以要考虑的问题就是如何使用和提升自己的能力去匹配“客户”的预期。对于管理者来说,最大的客户就是上级,因此,价值最大化的核心就是去匹配上级和公司的期待。
|
||||
|
||||
这是一种面向客户的视角,即,围绕客户的需要去发挥和提升自己的能力和价值。这个视角在“求生存”的时候特别好用,其逻辑是通过满足别人的期待,来获得自己生存的资源,因此也叫“生存视角”。你还记得上一篇文章中我们探讨空降时的要点吗?其中最核心的就是要厘清上级的期待并努力去兑现它,这对于在新的环境中“生存”下来是非常有效的,即是这个道理。
|
||||
|
||||
所谓未来视角,就是着眼长线,期望在更长的时间区间内价值最大化,从而让自己觉得度过的时间是值得的。如果说“生存视角”下的价值认定是围绕着“客户”的期待,那么“未来视角”的价值认定就是围绕“自我”的认同,所以也叫“自我实现视角”。同理,由于参照对象不同,即使把每个“当下视角”的价值都最大化,长期来看“自我实现视角”的价值也未必达到最大化。
|
||||
|
||||
那么,如何才能让自己更长期的“自我实现视角”的价值最大化呢?前提是需要有一个长期的规划,关于要走一条什么样的管理之路的愿景。要规划这个愿景,就需要综合考虑外部环境和内在因素,用我们中国人的话说叫“天时地利人和”。
|
||||
|
||||
|
||||
|
||||
管理之路的“天时地利人和”
|
||||
|
||||
首先,我们来看看“天时”。要想让自己发挥出价值,就得审时度势,看看我们所处的时代,有哪些大的趋势,以及顺应趋势有哪些机遇。作为管理者,这里我分享两个管理方面正在发生的变化,这两个方面未必是最重要的,但却是技术管理者们碰到最多的。
|
||||
|
||||
第一个方面,管理工作的底层逻辑正在从管控到激发。在[第 18 篇文章]我们探讨员工激励的时候提到,驱动力 2.0 的核心逻辑是用奖惩让员工“服从”,而驱动力 3.0 的核心逻辑是激发员工的“自主投入”。这种思维方式的转换不仅仅适用于员工激励,也适用于整个管理逻辑。这既是时代的需要,也是人的需要。
|
||||
|
||||
说是时代的需要,是因为我们正在从工业时代迈向信息和知识经济时代,人的价值体现,也从严格按照规程完成流水线的作业,到越来越依靠人的主动性和创造力,这在我们泛互联网领域尤其明显。
|
||||
|
||||
说是人的需要,是指在当今的中国社会,随着经济的发展和温饱问题的基本解决,越来越多的人从生存安全的需求,转移到价值认同和自我实现上,这对于 90 后、95 后的职场人尤其如此。
|
||||
|
||||
因此,作为管理者,我们需要调整管理的视角和心态,跟上时代的步伐。
|
||||
|
||||
第二个方面,职位头衔已经不再体现职责要求,我们需要从固化的职位要求中跳脱出来,从实际的工作需求去定义自己的职责和角色。虽然我们平时都习惯说要走什么技术路线、管理路线,架构师路线、经理人路线等,这都是为了降低沟通理解的门槛,却并不是职业发展的真谛和底层逻辑。底层起决定作用的还是“价值兑换”,所以,我们需要着眼于价值输出的最大化,而不是死板的职位要求。
|
||||
|
||||
常常有技术管理者问:
|
||||
|
||||
“技术总监的职责是什么?该做什么?不该做什么呢?”
|
||||
|
||||
“CTO 的职责是什么呢?它和技术 VP 有什么区别,如何分工呢?”
|
||||
|
||||
问这些问题的人,可能进入了这样一个误区:面向职位做工作,而不是面向客户。因为,只有职位对应的职责固定和明确时,这样的问题才是有意义的,而在我们互联网领域这显然不现实,因为不同的上级对于你这个职位的期待是千差万别的。另外,既然你的上级就在你身边,你不和他去确认,别人又有谁可以告诉你呢?
|
||||
|
||||
同样,在我们的管理工作中,你也需要帮你的下属去明确他们的工作职责和角色,使得他们的表现匹配你的预期。
|
||||
|
||||
时代的因素还有很多,总体上,我认为我们处于一个可以发挥自己价值的时代,而且幸运的是,互联网又是一个思想和技术都处于前沿的领域,不容辜负。
|
||||
|
||||
接下来,我们聊聊“地利”。即,技术管理者在职业发展中的优势有哪些。在我长期的观察和调研中,我发现技术管理者有如下三个通用优势。
|
||||
|
||||
技术优势。这很容易理解,既然是技术管理者,“技术”两个字就蕴含着其独特性。尤其是在技术管理之路早期,有一个鲜明的技术标签就是优势,比如你是电商类背景、社区类背景、App 开发类背景、大数据类背景、人工智能背景等,这些鲜明的标签很容易让别人了解你最擅长的工作。
|
||||
|
||||
逻辑优势。技术管理者由于其长期的技术思维方式,已经锻炼出了非常优秀的逻辑性。于是,这个在技术人眼中理所应当的特质,在管理者这个群体中就形成了独特的优势。甚至某著名投资人招聘投资顾问都只要技术背景的,因为他认为这样的人逻辑能力强。
|
||||
|
||||
执行力优势。在对超过 500 名技术管理者的调研中发现,项目落地能力或项目执行力是技术管理者们最拿手的管理主题,而且他们的上级也认同这一点。这其实和技术人的确定性思维也是分不开的,这是技术管理者的又一明显优势。
|
||||
|
||||
当然,前面这三个是技术管理者普遍具有的优势。那作为个人,你自己有哪些独特性优势呢?你可以问问自己如下这几个问题:
|
||||
|
||||
周围的亲人朋友、上下级同事都喜欢用什么词来评价和称赞你?
|
||||
|
||||
是什么让你与众不同?在什么重要的问题上,你与其他人有不同的看法?
|
||||
|
||||
是什么让你取得现在的成绩?你在管理工作中突出的能力是什么?
|
||||
|
||||
你更关注事,还是关注人?如果是关注事,你更喜欢“想事”还是“做事”?如果是关注人,你更喜欢“支持人”还是“带领人”?
|
||||
|
||||
通过认真思考以上问题,可以让你对自己的优势有个大体的了解。而如果你想更深入了解自己,可以参考盖洛普(Gallup)的优势识别器 2.0。
|
||||
|
||||
最后,我们聊聊“人和”。在职场发展中,最重要的“人和”因素是下面三个。
|
||||
|
||||
上级。上级的信任值得珍惜。对于做管理来说,最大的“人和”就是得到上级的信任和支持。原因很简单:我们的目标是和上级一起定的,资源是向上级申请的,工作结果是上级来评价的,你会发现我们管理中的“看方向”“带人”和“做事”都是离不开上级的。所以,如果有一个相互信任的上级,请务必珍惜,努力成长让自己配得上一直追随他;如果还没有相互信任的上级,请务必重视去经营信任关系(关于怎么经营信任关系,我们在[第 32 篇文章]中有介绍)。在管理之路上,“跟对人”无疑是一条“捷径”。
|
||||
|
||||
伙伴。同事伙伴的陪伴力量很重要。和一群优秀的人一起成长,无疑是非常有意义的事情。你们可以互相切磋一起成长,并且随着时间的推移,你们都会成为“独霸一方”的人才,你会发现你们的相互影响是指数级的。所以,请珍惜身边的同事。
|
||||
|
||||
个人。个人的愿力是一切的源头。关于人的因素,除了外部的人,自己的愿力也是非常重要的。如果说我们需要为自己一切的努力找到动力源泉的话,规划自己的愿景并明确自己的使命,无疑是非常有效的做法。这也是本文的意义所在。
|
||||
|
||||
好了,如果你从“天时”“地利”“人和”出发,分别去盘点自己的时代机遇、自己的独特性优势,以及自己的愿景和伙伴关系的话,是不是就可以回答自己这样一个问题:“在未来 1 年、3 年或 5 年、10 年以后,我会成为一个什么样的管理者?”
|
||||
|
||||
怎么样?能够回答自己了吗?
|
||||
|
||||
我猜想,大概率你还是不能。因为愿景规划不是一个立刻可以明确的事情,所以,不要指望看了一篇文章就清晰起来。不过,若是这篇文章能够给你提了个醒,让你开始思考这个问题,也算是非常有价值了,不是吗?
|
||||
|
||||
即便如此,在最后的最后,我还是有两句话要交代:
|
||||
|
||||
请耐心地给自己成长的时间。这个时代的快节奏带给我们很多的焦虑和不安,仿佛一不小心就会错过什么。其实,职业生涯就像一场“马拉松”,很漫长,5 年或 10 年可以发生很多事,而你的生涯可能是 20 年、30 年,甚至可以像我一样,贯穿整个余生。在这么漫长的岁月中,肯定有人“先胖”,有人“后胖”,不用着急。成功其实很容易,因为所有的失败都不叫“失败”,都只是“尚未成功”而已;只要有一次“成功”可以让你足慰平生,你就是个“成功者”。互联网拉平了世界,你随时都有时间和机会去赢得自己的成功,或早或晚。
|
||||
|
||||
用自己最擅长的姿势,开创属于自己的发展之路。不是前人走过的路才叫路,也没有什么规定好的“管理之路”是你必须要走的。因此,也就不存在所谓的“弯路”,所有你走过的路都是你的成长之路,这条路是你自己开创的。事实上,所有的路上都有一条法则是奏效的,那就是“价值兑换”,所以,做技术不重要,做管理也不重要,把技术和管理当成你职业的两条腿,在职场中输出自己最大的价值,才是最好的,才真正属于你。切记,不要被别人的路限制住,也不要被某个职位限制住,没有哪个职位可以定义你的职业发展。
|
||||
|
||||
好了,本专栏到此就结束了,纸短情长,后会有期。
|
||||
|
||||
希望这 36 篇文章可以带给你一个看待工作的视角、一幅管理的图纸、一颗个人发展的种子,陪你走过管理转型之路。期待你带着这个视角、这幅图纸和这颗种子,在具体的管理工作中不断“事上练”,收获属于自己的精彩。
|
||||
|
||||
|
||||
|
||||
|
Reference in New Issue
Block a user