Skip to content

Latest commit

 

History

History
69 lines (35 loc) · 10.9 KB

ch2leading.md

File metadata and controls

69 lines (35 loc) · 10.9 KB

第二章 领导团队

你所在的环境大概分两种:大公司和小公司。大公司像是IBM和百度阿里腾讯,技术员工有之职业等级,每年都有考核升级的机会,升级之后薪水和职责都会有改变。小公司没有这个划分,在研究机构和大学的课题组、创业公司等,想要获得晋升的途径有限。如果你在的公司足够小、足够扁平,或者你所在的项目足够短暂,那么员工的晋升途径就是升管理(你)或者跳槽(你的组员)。

本章描述我在小公司环境使用的管理方法,简洁粗暴,在你的小团队里面建立一套职业晋升方式。这套理论的核心概念只有两个思维模式、一个分类法,分别是“五十年后思维模式”、“面向简历思维模式”、“挑战、巩固、苦力活分类法”。

五十年后思维模式

在思维模式上的第一个转变就是将眼前的工作和项目管理,放在未来五十年的时间框架里考虑。

五十年内,你的员工会离开你的项目组,离开你的公司,有更好的发展。你的组员跟你共事的时间只有三个月或两年的时间,这段时间是他(她)职业生涯中的一个台阶。面对组员的时候可以问自己,十年之后这个组员会如何评价你在她(他)职业发展中起到的作用,是正面促进的作用,还是浪费时间更多一些?

五十年中,团队会解散、重建、壮大、调整。你和组员的领导关系只是你跟他(她)这五十年间关系的短暂形态。相遇过的人很有可能再重逢,如果提前知道以后你的组员可能在一个新的公司跟你成为同事、下属、抑或上级,再审视当下的日常决定,可能会有一些微小的改变。

五十年后大家都死了。我不是开玩笑啦(好吧,有一点)。当你因为项目工作的分歧变得言语激烈,甚至开始有攻击性言论的时候,想一想五十年后。

面向简历思维模式

“面向简历编程”是IT界的一句玩笑话,你可能看过也笑过。这个戏谑的说法有一点贬义的成分,我觉得隐含了“面向简历编程就不是为公司干活,是对公司有害的自私行为”的意思。这种对立的思维是错误的。好的组织(公司、研究机构、创业团体),能够给成员提供的不应该只有钱。放在五十年后思维模式里面看,在工作的同时,个人是需要有提升和发展的。这种需要体现在简历上,并不冲突。

一个经典的说法是西班牙模式和英国模式。西班牙模式觉得世界财富是固定的零和游戏,所以采用掠夺手段;英国模式觉得财富是不断增长的,大家通过交换都能赚钱,所以采取工业革命和贸易。我不知道我的类比是否正确,你能够理解我想表达的意思就好(^_^)。在西班牙模式下,组织从成员那里付费获取成果,成员有薪水之外的收益表示组织榨取的程度不够;英国模式中同样的组织从成员那里付费获得成果,不同的是认可成员自身能力的提升是双赢的结果。

那么落实到你和你的小团队身上呢?难道直接拿出来组员的简历跟他讨论当前这个项目结束之后简历怎么更新完善?

对。确实我是这么做的。

我在中科院下属一个科研机构工作的时候,需要招聘实习生。我们是事业单位,在北京,没什么钱,实习工资很少。跟我们竞争优秀实习生的公司很多,百度、阿里、腾讯能够提供的实习生工资比我们高很多,而且名气也比我们的大很多。如何吸引周边北大、清华、北航、北理工这样学校的优秀学生?在招募和培养一段时间实习生之后我发现了我们的优势所在。我见过很多的实习生,非常优秀,进入知名的大公司之后做的工作却多数是我们后面说到的“苦力活”。在实习期结束之后简历上不管怎么修饰,最后能够体现的就是“我的能力足够优秀,BAT录用了我做实习生”。在这点上我能够提供给实习生的就要多很多了。我所处的环境是国有科研机构,绝大部分工作都是开源的,实习生可以在简历中直接引用他们的工作成果;同时我们重度依赖实习生去跟踪和复现最新的研究论文的实现和结果,这样我们能够提供给实习生的挑战,很充实。进一步的,我们将实习生的研究报告、系统代码实现等都放在GitHub上。在实习结束之后,我会帮助实习生完善简历。这对于实习生在实习期结束之后的校招有着非常大的帮助。

正式员工或者合同工并没有实习生那样明确的离职时间点,这让你不能照搬用于实习生的方法。我的方式是在1on1(一对一谈话)的时候,直接询问我的队友的职业发展预期,以及优先看重的是什么。可以按照半年、一年、两年这样的时间节点进行讨论:“半年之后你希望能力经验上有什么收获?”,“一年之后你希望自己发展成什么样子?”,类似这样。当你的队友跟你敞开心扉,你们就可以开始寻找三个目标中共同的部分:组织建立这个团队的目标,作为组长的你的个人的目标,你面前的这位队友的目标。下一小节的思维模式告诉你在明确目标之后如何实现或体现你们的共识。

要做到这点,首先需要你的坦诚,坦诚地看待自己的目标和组织、队员目标的差异,坦诚地跟队友表达你希望帮助他(她)成功;其次需要谨记这是建立在信任和私密性的基础上的,面对面坐下来聊这个事情,使用即时通讯或者电话交流可能会增加对方被录音、截屏的担心,信任伴随着守密的责任;最后跟对方明确哪些是你的权责范围可以帮助的,哪些超过了你的权责能力,大包大揽的空头支票瞬间就会让你失掉信任,让对方觉得你只是想要套点话然后去告密。

挑战、巩固、苦力活分类法

当你跟你的队友明确了目标之后,接下来团队要做的工作就可以按照“挑战、巩固、苦力活”三类进行简单的划分了。划分完全按照队友的目标和主观感受为标准,你要做的主要是引导队友进行划分,告诉你分类结果。

挑战类的工作是指对于组员而言有两个特征。第一个是没有接触过的技术领域、第一次接触的工作内容、或是之前尚未成功过的工作。第二个特征是组员感兴趣,并且愿意去做。这类工作自然地可以更新到组员的简历中。理想的工作是在组员的舒适区之外,通过努力能够达到,又不至于难到明显无法实现(这里盲目乐观设计不现实目标的更可能是组员,而组长的你需要察觉并调整到合理范围)【TODO插入一张图解释】。

注意到这里对你的技术能力有一个潜在的假设。这种假设在第一章 准备工作中有提到。

对应的,苦力活对于组员而言满足两个特征中的任何一个:第一,组员没有兴趣;第二,组员已经非常熟练。这是完全主观的评价。即使现在人工智能非常火,很多人都想做,但是如果你的组员只喜欢做操作系统内核驱动开发,那么对于他而言你分配给他深度学习方面的开发工作就是苦力活,即使你自己觉得对他会很有帮助。员工已经非常熟练的工作不能够给员工的简历更加新的亮点,也不能够给他的个人技能提供进一步的提高。这类苦力活有一个好处可能是被你忽视的:这是在舒适区的工作,做起来心神舒畅,效率超高,能够获得安全感、幸福感和少量的成就感。舒适区里的苦力活就像是垫肚子的米饭一样,多少需要吃一点。

巩固类的工作就是在组员愿意的前提下,既不是完全熟练也不是完全陌生的工作。这类工作对于组员而言是最甜蜜的工作:有足够的信心完成,又觉得能够获得技能提升和简历更新。

对于你而言,在分配给组员任务的时候,需要将这三类工作搭配着来是最好的。其中对于组员而言,自己不喜欢的苦力活是最应该避免的,别的工作分配好之后你都不需要操太多心。理想的情况是每个人都做着自己喜欢做的挑战、巩固和苦力活套餐。下一小节告诉你如何(尽量)做到让每个组员都高兴。

任务分配的团体动力学

秘诀就是注意到每个人的技能和喜好都是不一样的。在一个技术小方向上,一项工作任务对于老王可能是苦力活,对于小张就是挑战。那么你要做的就很明确了:在收集了大家的目标和反馈的基础上,在组内做分配即可。同时,注意这种“苦力变挑战”的关系隐含着建立一条组内1on1互助关系的可能性。

肯定有大家都不愿意做的事情。这个时候就因人和任务而异了。简单说没啥好办法,确保做苦力活的人不会不爽到发飙就行。

首先是可以尝试改变一下观点,尽可能地将这种苦力活儿转成有挑战的事情。如果你有权限,可以考虑招募新人或者实习生来做(前提是满足面向简历的模式)。如果临时性的工作,小工作你就自己做了。如果你一个人吃不下,那就尽量大家都均匀地吃一点。吃这个东西的时候,不患寡而患不均的情绪会比较多。你需要逐个安抚,开会群抚可能会起到反作用。

一些管理的细节

找机会团队一起吃饭。有的组织提供吃饭的经费,这样的公司更能留住人。国家科研机构这样的没办法报销,你可能需要自己掏钱创造吃饭的机会。简单工作餐或者平民消费餐厅就非常好了。相信我,这个钱你花的值。团队有时候也会AA或者有人跳出来请客。团队不大的时候,这些都是OK的。喝下午茶也挺好,开会的时候吃零食和小点心也同样好。

一对一的讨论和你自己的技术判断要比周报之类的准确很多。

如果你无法踢出去搭顺风车的组员,那么在任务上进行明确的区分。尽你所能将干活的人和不干活的人隔离开,并且让干活的队友知道你的目的。

超越基层管理

有关基层软件项目管理的方法已经阐述清楚了。千真万确。

那么以后呢?可能你会有大的团队和项目需要负责,也可能会继续在管理的层级上向上走。也可能这次项目管理只是你职业生涯中的一次小插曲,项目结束之后你回到研究者或者技术专家的位置,不再从事管理的工作。不管是哪一种,我相信这本小册子都会改变你看待团队管理的角度,或许也会改变你看待未来的态度。

我对于更高级别的管理经验不足,不足以给出指导。但是有一条经验我很确定普遍适用:不要相信周报里写的东西。