Tag Archives: 团队

管理50人以上的团队

一、题目

  21年写BLOG说:“接下来要开始动手调整团队,招聘P7,培养年轻人,筛选考核中层,构建班委。总之,计划用半年时间,把事情交出去,把SOP定好。”

  事非经过不知难,原本预想大半年,迭代了一年半才算达标:建立部门班委,培养了一批年轻的一线lead,同时建立了各个岗位的SOP,原本必须由P7盯的工作现在让P5依靠check list、CI/CD也能顺利完成。

二、起因

  21年初,团队工作顺利,周围评价不错。但自己心里清楚:我的管理半径大概是两层汇报关系(也就是说,大概最多管7*7=49个人),以往我带团队超出50人的规模就会出问题。这一次原本想一直带40人左右的中型团队,控制规模,集中精力做产品,独善其身。

  但CEO在战略上不断加码,期望我和团队承担更多事。

  我犹豫权衡了很久。承担不擅长的的大型团队管理,会有压力、情绪和人际关系冲突。万一突破不了,陷于平庸,涉及到整个公司的成败。我得有自知之明,深入思考。

  有天晚上我和Summer聊到半夜3点,我意识到她也面临小马拉大车的问题,但人家没纠结就上去担当责任了。暗暗有些惭愧,第二天去找CEO说,我想明白了。

三、过程

  下定决心,然后开始解决问题。

  问题本质是什么呢?只有三四十人时,团队长作为业务专家身先士卒就够了:软件工程、晨会周报、修理不靠谱的,赞扬躬身入局的,随时回忆历史经验供年轻人参考……然而,一旦带领上百个人,就很难直接辐射到每个一线员工,甚至记不清楚很多同事的名字。这时候只用老办法,把自己累死不说,也容易出现办公室政治。

  在HRBP的协助下,组建了班委,制定了关于组织的ORK:招聘多少人,培养多少lead,lead的考察期标准怎么定义,定期One on one怎么做……然后又要求PMO把最关键的POC、交付等流程的规定动作沉淀到系统里去。最后,要求devops负责人彻底把CI/CD做透。

  有个阶段甚至发起“去地雷”的运动。把流程和owner贴到IM的自动回复里。强行从各种一线业务里退出来。调整心态,克制自己动手的冲动,眼睁睁看着年轻人掉到坑里再爬出来。

  尽管准备很多,落地过程中还是经历了不少波折。曾经reorg半年后又调回来;一些lead考察期不通过,需要降落回去做不带人的高P专家;招来的人不靠谱又请走;压力非常大导致失眠和暴躁;还有疫情的考验;还有公司并购牵涉精力……

四、总结

  现在总结,最有价值的举措是建立了部门班委制度,班委这个制度不是任何时候都可以实施的。我运气好,有三观正、专业靠谱、沟通顺畅、可以把后背交给对方的班委和HRBP。班委制度的核心是信息完全透明充分同步,初期甚至“过拟合”,从而让认知一致决策一致。关键场合,只要有班委其中之一在场,就可以拍板决策。换其他班委,决策都会一样。

  另一个关键是每2个月One on one一遍Lead和骨干。这事累心,有时候聊的想吐,但很有效。所以我们坚持雷打不动。这方面,我特别感谢自己的HRBP(以后昵称“SQL”),没有她的督促和协助,我这么懒散的人根本坚持不下来。美女SQL在HR方面很专业靠谱,还会写C++,这是我们团队的重大竞争优势。

五、结果

  用了一年多算是把新的机制落地了。今年收购GIO那2个月,我自己完全飘在外面没怎么管家里,同时团队正在夜以继日做重大技术攻关,再加上疫情带来的问题,幸亏有了体系准备,团队靠优秀的班委和年轻一线lead齐心协力扛住了复杂局面,完成了目标。朝着S级平台工程团队又进一步。

软件研发和团队交流

  下面每一段话都源于近半年的亲身经历,很多话是拥有十几年软件经验的老兵的原话。

  当了pm,尤其是没有界面不需要Axure的底层Web Service的pm,依赖一支巨大的分布式团队,面对不止一家强势客户,交流就成了最关键的任务。半年前我还是中科院里一个不折不扣的技术宅男,与生人聊非技术话题有障碍,害怕给陌生人打电话,外出聚餐拿菜单看半天也不知道点什么。幸运的是,跳槽后碰到几位好上级,每次掉进坑里都能获得诚恳的建议,甚至专门帮我复盘。

  我有每天记录想法的习惯,很多内容整理之后就发BLOG。但这个“团队交流”的主题等了很久。涉及公司内部信息,无法带上具体场景,很多血泪经验就成了糖水大道理。也因为积压太久,即使只放是糖水大道理,慢慢也存了很多段。不管怎样还是发出来吧。

  公司一直在剧烈重组。以往我设计软件架构很少考虑人的交流因素。现在算是理解了著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是:什么样的团队组织结构,最终就会开发出一模一样的软件架构。如果有四个团队合作开发编译器,系统最终一定会长成一个四阶段编译器。所以大型软件组织内,在重构系统之前往往先reorg团队。对分布式的团队,更加如此。前一阵很多人在Blog里写分布式团队的交流问题,用了很多招数,例如两边架起摄像头和大屏幕,形成一个虚拟的统一环境。

  到飞天团队,发现与以前在pFind倡导的工程实践没太多区别:SVN、BugFree、定期重构、单元测试、站立会议、代码review……所不同的是执行。飞天主力是微软出来的,有软件工程基因。制度和团队平台给力,就算是大三实习生也能大展拳脚,两三天内完成千核并行复杂算法的剧烈重构和测试。实际上pFind团队规模已经很大了。飞天内很多小team总共才四五条枪,而且大多是本科刚毕业甚至实习生,有些专注于统计机器学习的算法团队,工程产品也非常宏大。这是人际沟通和工程效率问题,不是学术或工程的非此即彼的投资方向选择。对pFind感情很深,希望后继者有勇气和智慧做到我没能做到的。

  敢提出傻问题是有责任心的表现。很多新人、边缘人、接口人都有交流障碍:不敢把点子或疑问拿到桌面上来,借口是:还不了解情况,等我彻底变成“自己人”再说。怕问错了显得不够牛,或者问对了牵涉别人的利益。明哲保身是动物本能,但它仅仅在黑暗森林低级生态环境下才算是最佳策略,在一个有序、专业、理性的团队里,过分谨小慎微只会显得无能,让别人放弃对你分享信息。反过来,直言不讳也是一种压力测试,可以借以观察团队氛围是否正常。

  tech lead最重要的素质是充分沟通的勇气和器量,“领导和下属之间应该’下棋’而不是’打牌’,在信息对等的情况下决策。尤其是坏消息,必须第一时间告知下属,坏消息往往传得很快,最好让下属从你这里首先获知。”反过来,最愚蠢的举动就是伤害团队对自己的信任。情绪管理、私人利益、交流效率都对信任感造成影响。

  网络公司的技术团队往往被分为前端团队、后端服务团队和基础平台团队。不同类型的团队交流和思考的方式不同。出色的基础平台团队,节奏感往往非常强,知道先做什么后做什么,一开始只做最难最重要的事。

  需求分析的时候,用户经常是在告诉你怎么做(How),这些信息没用,你要问清楚他们的本质需求(What/Why)。用户说要什么就做什么往往死得很惨。福特说:“如果最初我去问顾客想要什么,他们一定会说:一匹更快的马”。

  技术->项目->产品->服务,这是个漫长的进化过程。和一个陌生的技术团队聊,最重要的就是评估他们在这条打怪升级的不归路上位于何处。已经拥有成熟服务的团队会问你:“需要多大程度的可用性?我们的服务目前能达到五个 9,也就是一年无故停机最多5分钟。”(关于服务怎么运维,现在DevOps讨论很热,推荐看看这个