刚结束三天两夜的公司年会旅游,在等大巴时,某同事问了个非常标准化的闲聊问题:Luna,你周末有什么安排?
我认真地说,我准备做这个月的复盘和总结,回顾目标的完成情况,制定下个月的目标和计划。
emm,原本比较轻松的氛围,好像一下子都被我的认真回复震撼了。
不禁想到,在很多很多的社交场合,我都面临着两个以上的选择:
绝大多数时候,我选择的都是第一种,即使我知道,我的回答听起来没那么「正常」。
下面开始正文。
我目前的团队里面有 10 来个程序员,绝大多数都是新人,在校大学生,这是他们的第一份 IT 工作。
带人是我工作的主旋律,在带人的过程中,我也不断地在思考,面试的时候看起来能力相似的候选人,到底是什么原因,让实习生 A 能够脱颖而出,实习生 B 则进步缓慢?
结合之前看的书和一些讲座,我认为答案就是:「内在标准 + 良好的工作习惯」。
每个人对「完成」的定义不同,我在团队 kick-off 的时候,特别强调了 High standard of definition of Done 的重要性。
一个低标准或者无标准的实习生,认为做完了就是做完了,TA 不求甚解,TA 满足于别人告诉 TA 的信息,没有花时间用心进行更加深入的思考。
请注意,这一步完全跟智商无关,我会跟每个人说同样的话,会针对 TA 在做的任务给不同的 tips,有些人能听进去并去执行,有些人则听不进去,我最怕的是那种假装听进去/做表面功夫的。
说三次之后依旧无效的,我会有点失望,因为这是个纯粹的态度问题,如果你不珍惜,我为什么要浪费我的时间和心血来「培养」你?
如何定义工作习惯是否「良好」?
首先,也是最重要的一点:动作不变形。
当一个新人接收到一系列的任务指令后,能保质保量地按照标准流程做下来,就已经是佼佼者了。
第一次做不到,很正常,如果在交付之前有人会专门来跟我再次确认细节(而不是根据自己的猜测去完成),在我心里这是个加分项。
我清楚的记得,我三年前刚开始工作的时候,做了一个 UI 相关的需求,我有了一个大致的版本后,马上发给了 UI 同事,问这是不是你想要的效果,TA 给了回复,并且非常开心地说,我很喜欢你在工作过程中来找我确认,可以省掉很多后续的沟通和修改成本。
我当时没觉得这是个多么了不起的工作习惯,直到我开始带人了,才发现这个习惯有多重要。
一个新人,越愿意提问,越能搞清楚正确的动作到底是什么样的,越是能够尽快上手标准化的流程,越能拥有比别人更快的进步速度。
注意:这一步即使文档再详尽,也无法代替人际互动和沟通,因为不同的新人有不同的技能水平,会卡住的地方也不尽相同。
第二点,注意自己的仪表、谈吐、举止,让自己代入「职场专业人士」这个角色。
简而言之,那些穿着过于随意、迟到早退、上班狂打呵欠甚至会议上睡着、事情做不完也觉得无所谓让别人帮忙擦屁股的新人,都会让我一声长叹——祝你们早日长大成人。
每个公司都有不同的新人培训流程,我觉得这个环节最大的风险就是新人匹配的那个「老人」自己都搞不清楚流程。
那么,从新人的角度来讲,如何降低自己「被坑」的风险?
很简单,跟团队中其他人(尤其是靠谱的,能把事情说清楚的那些人)建立良好的关系。
原因?没有任何一家公司/一个上级会反感一个新人去问团队中其他人问题,如果有的话,早日离开这家公司。
另外,如果你是「老人」,你带的新人总是绕开你去问别人问题,你可以反思一下,是不是自己的教学水平有待提高。
职场新人(工作1-3年的)一定要把自己的注意力放在这两个点上:
第一个点可以让你的工作质量高于平均值,你的上级很快会注意到你做的东西质量好,返工率低;
第二个点可以让你的工作速度快于平均值,在同样的时间内完成更多的事情,有机会获得更大难度的任务,成为被提拔的头号种子选手。
PS:这里我没有着重聊「情商」,因为能做到以上两点的人,据我观察,情商都不低。
很多新人的通病是「眼高手低」,觉得自己做的事情太简单太无聊,如果一个人意识不到自己在标准和习惯上的问题,在管理者眼中,这些人就无法委以重任,只能负责一些流程化和低风险的事情。
可能你正处于「你认为自己怀才不遇、上级认为你不够成熟」的这个负反馈闭环中。也许你的上级曾经给过你一些对你有帮助的反馈,但是你当时不够珍惜;或者你的上级过于nice,不愿意做那个「坏人」。
不管是哪种情况,你破局的唯一方法就是——自省 + 主动寻求反馈。
如果你的上级不愿意说实话,找别人问,观察自己跟团队明星成员之间的差距,然后制定有效的行动方案。
如果你不主动去做这件事,你会永远处于「怀才不遇」的负面情绪中,认为你这块金子被埋没了;当然,在外人看来,你还是那个「眼高手低」的小菜鸟。
这个月我还有一个重大的思维转变,这个转变来自我刚看完的一本书——An Elegant Puzzle: Systems of Engineering Management。
我在入行三年的总结文章中提到过这本书,它是我管理成长之路上的「关键知识」。
这本书戳中了我很多很多,最关键的一点是:kill the hero developer。
每个团队都有一些明星成员,尤其是开发团队。
那些天才/英雄程序员总是一切了如指掌,能以比别人快 n 倍的速度,发现问题、解决问题,让其他人投以羡慕的眼神。
这类带有英雄色彩、能拯救整个项目的明星是怎么来的?是领导者一手培养的。
某一天,有个紧急任务,领导者把这个任务布置给了明星,明星完成了,技能点增加了,领导的任务解决了。
周而复始,明星的成长速度快于其他人,接到重要且紧急任务的次数也远超其他人,形成了一个牢固的反馈闭环。
明星程序员任劳任怨,加班加点做紧急任务,直到陷入职业倦怠(burnout),进入一种不健康的「高效」工作状态;或者明星程序员发现,身边的人都太弱了,完全跟不上我的速度,我应该换份工作。
想要打造一支健康的高绩效团队,管理者必须狠下心来「Kill the hero developer」,而做到这一点的关键在于「Kill the environment that breeds hero developers」。
PS:如果你是文中的 hero developer,你要仔细思考如何避免明星程序员的两种命运,如何定义自己在团队中的位置,如何避免产生职业倦怠。
这本书里面讲了不同的团队发展阶段,以及不同阶段的团队需要着重解决什么问题。
我看完之后恍然大悟,原来带团队也是有「方法论」的,我以前是那个摸到大象一条腿的瞎子,现在则开了全局地图,能清晰地看到我所处的路径和前方的挑战。
比如我总在想,为什么大家不能工作更努力一些?似乎只要足够努力,项目延期的问题就可以解决了。
作者一针见血地指出:让大家更努力,只会营造出孕育个人英雄的环境,英雄和「平民」之间会有越来越深的隔阂,而你的项目问题依旧无法解决。
简而言之,个人英雄主义无法解决系统性的问题。
反复光临的紧急项目和团队压力意味着管理出了问题、流程出了问题、公司出了问题,我们要解决根本问题,而不是让大家更加努力。
作者甚至建议:假如你目前的职责权限无法改变这个错误的流程,那么你要做的是加速这个流程的崩塌,而不是尝试用英雄们来掩盖/缓解流程问题。
Without policy, your tool is stepping back and allowing the brokenness to collapse under its own weight. A deeply flawed system can’t be saved by band-aids, but it can easily absorb your happiness to slightly extend its viability.
If you step back, you conserve your energy and avoid creating rifts by pushing others away in hero mode, and you will be ready to be a part of a new—hopefully more functional—system after the reset does occur.
This is a very uncomfortable process, and if you’re a hardworking, loyal person, then it probably goes deeply against your nature.
这部分的分析带给了我无尽的思考。
我知道,我曾经、乃至现在,就是那个英雄,我以为我需要的是更多的英雄同伴,但我错了。
管理解决的是人际合作的问题(Management means solving human collaboration problems),我要做的是「破 + 立」。
坦率地说,这个月,我 burnout 了。
持续的高压 + 多个项目多条主线并行 + 紧急项目 + 身体不适 + 精力衰竭,让我病倒了两天。
我诚实地告诉领导,我无法承受更多了。
于是,我期待的变革,正式拉开了帷幕。
与之前不同的是,以往的变革,我是那个被动接受者+执行者。
而这次,我是核心设计者之一。
我要达到的目的很简单:通过改革流程,打造一支不需要悲情英雄的高绩效团队。
PS:也许你注意到了,高绩效团队可以拥有很多明星员工,但是这些明星员工有良好的工作生活平衡和职业发展,不是那种「反复被拉去力挽狂澜 + 一个人等于一个团队 + 填补掩盖流程缺陷」的悲情英雄。
敬请期待后续:)