技术人员如何快速成长为初级管理人员(直接管理人员)
1.技术人员转管理的坎
身份认同混乱
身份认同混乱,是技术人员转为初级管理者时的通病。一方面觉得技术转型管理,拓宽了技术人员的职业天花板,打开了人生的另一扇门;一方面又觉得管理好像一门“玄学”,虚头巴脑的,看不清摸不透,还是技术实在,常常会认为如果丢掉了技术我靠什么安身立命?这个问题在技术人员转型为管理人员的很长一段时间都会有这个错觉。身份认同混乱会导致自己的工作重心飘忽不定,导致工作总不是那么尽如人意。
思维方式不同
技术骨干更多的是关心“事”,关注工作是否顺利完成;而管理者更关注是否充分挖掘了每个员工的最大价值,团队成员是否已经尽了自己最大的努力;
技术骨干在工作上常常习惯从深处、细微处着手;管理者则并不苛求每一个细节都完美,主要是宏观把控,因而很多事情处理起来显得不够精细和具体;
技术骨干坚持非黑即白的是非观,由于长期从事技术活动,更相信经过反复验证的事情,是非权责分明;管理者则认为在管理中没有绝对的正确或错误,只要不违背一些特定的原则就可以,所以他们在观念上也就没有非黑即白,而是因人而异,具体问题具体分析;
技术骨干做事只对事不对人,无论对客户还是上司,就事论事,不会变通,更不会因人而异;管理者则坚持对事也对人,常常根据具体情况作出对应的反应;
技术骨干更多的是享受过程的乐趣,对于结果并不过分重视,只管耕耘;管理者则更强调工作的结果和价值所在;
技术骨干在工作方式上是“算加法”,通常是完成一件事再去做另外一件;管理者则是“算乘法”,所有关键要素齐头并进,其中任何一个要素都要求配合完成;
技术骨干倾向于收敛思维,思考问题时思维模式单一化、机械化;管理者则是发散思维,强调融会贯通;
技术骨干做每件事都需要量化的指标,坚持科学的观念;管理者更多依靠的是与“科学”相对应的概念性的理念;
综合以上特点,技术骨干相较于管理者更固执、刻板,管理者则灵活许多,更富有弹性。要想成为一名优秀的技术型管理者就要熟悉这些特质区别,只有知己知彼方能百战百胜。
能力的切换
管理工作所需要的知识面与能力结构更加宽泛。具体来说,管理所需最基本的能力包括:计划能力、组织能力、协调能力、沟通能力、监督控制能力、决策能力。
技术工作相对单一、聚焦,也相对单纯,答案比较确定。技术骨干主要是以本人的工作为主导,也只是对自己的工作成果负主要责任,“把自己的事情干好就可以了”。
管理是一门微妙的人文艺术,管理活动是所有人类活动中最为丰富、最为费力、并且毫无疑问是最为复杂、最为微妙的活动——马斯洛。
成为管理者之后,就是以推动团队的整个工作为主导,要对整个团队的总体工作结果负责。工作的方式主要是计划、会议、沟通、激励、绩效管理和危机处理等,是要通过带领下属一起去完成任务。在这个过程中,从技术岗位转为管理者的人通常会犯以下几个典型的错误:
(1)事必躬亲。认为下属的能力达不到自己的要求和预期,或者对下属的工作质量总是不放心,既不愿意花时间培养、又不愿意授权,什么事都揽在手上,弄得自己非常疲惫,同时员工也难以成长,管理者自己成了团队业绩的瓶颈。
(2)不注重激励员工。由于技术人员关注品质、追求完美的习惯,对下属的工作总是只看到缺点和不足,常常批评员工的工作不到位;而员工做得再好,都觉得应该,久而久之,员工就觉得领导总是挑刺,从而产生抗拒心理。
(3)缺乏沟通技巧。“管理即沟通”,管理的整个过程都需要沟通来实现。然而很多技术背景的管理者,精于专业而拙于沟通,他们往往沟通方式过于简单、直接,常常弄得沟通对象下不了台,以至于成为管理工作的障碍。
2.初级管理者的要点
结果导向
对于初级管理者,最最重要还是要用结果说话,如何取得良好的结果,有两点非常重要,一个就是任务分解后的结果是可度量的,有明确的标准。另外安排下去的时候一定要清晰明确,布置任务要说五遍,“交代-复述-目的-风险-个人想法”,详细参考《樊登可复制领导力》或者《与这个时代最有梦想的人一起成长---混沌大学开学典礼有感》
团队战斗力
一个战斗力强的团队一定是团队氛围非常好的团队,怎么做好团队氛围和团队建设是非常重要的一件事情,需要管理者不断探索与实践。这块内容比较多,回头更文专门解读。
选人与开人
网上流传一句“开过10个人以上才是管理入门”,我对这句话深信不疑,在很长地一段时间觉得我的管理水平还可以,直到在上家公司一下子裁员20多人时,才真正体会到这句话的真是含义。
只有开过人,面试时你才会真真正正思考,公司和团队到底需要什么要的人?才能真正做到对公司和面试者负责。
另外,在合适的时间点开人才能够获得利益最大化。
3.如何一步步从技术跨越到管理
风险管理与担当
作为管理者,第一要紧的事就是担当;如果员工出错,第一个做错的肯定是你,因为有可能是你没有合理的最好工作计划和管理风险;也有可能是因为没有培养和辅导员工的工作绩效和工作能力。
另外作为管理者最重要的是分解任务和管控风险,任务分解对初级管理者也是非常重要的技能,但大多在管理以前都接触过一些训练。但风险管理是初级管理者最需要提升的最重要的技能,需要在制定任务计划是充分的考虑任务和项目的风险都有哪些?需要在制定计划的时候就制定一个风险list列表。
提升自身的影响力
这块内容前面太多的内容提到这块,如果有兴趣欢迎参考前面的文章。这块特别要说明的是,对于初级管理者来说,虽然技术不是第一重要的,但保持对新技术、新趋势的敏感还是非常必要的。
不断总结,自我反思
在我个人成长过程中,有一个非常重要的方式,就是写管理日记。
总结自己做的事情,那些完成了,那些没完成,并说明为什么没有完成?
反思执行过的事情,那些做的好,那些做的不好,需要怎么去改进,都记录下来。
思考第二天需要做的事情列个to do list 并且标明重要程度和优先级。
对于总结方面,其实和时间管理有很大的挂钩。因为一个管理者的时间常常由被动时间和主动时间所构成。而所有的「主动时间」都应该花在总结上,作为一个管理人员来说,需要对各种事情做有效的排期,最重要的当然要放在最前面。
“向上管理”能力
这方面的能力还是我当下比较欠缺的。目前仅仅是做好了及时回馈自己的工作进度以及公司每天要求的日报。但实际上在“向上管理”层面,我能做的还差的很多。有经验的朋友也欢迎多多留言。
如果没有这个“向上管理”的话,你可能把整个团队都给带偏了,最后老大会说我要的并不是这个,我要的是另外一个东西。所以说一定要做好向上管理。
以上是我对初级管理者的一些浅显的看法和总结,这篇文章前前后后写了3周多,一直觉得不够满意,一方面是因为自己实在太菜,另一方面也是因为管理工作确实是一个比较复杂的工作。希望大家多提宝贵意见。
2019年连续二十九天修心,土司于北京
如果你喜欢我的文章,欢迎关注扫描公众账号:MiniStarClub
上一篇: 技术管理转型(I)--对技术管理的看法
下一篇: 简述操作系统的四大功能是什么?
推荐阅读
-
技术人员如何快速成长为初级管理人员(直接管理人员)
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为: