大厂技术高管如何融入创业公司
The following article is from 思辨致知 Author 日之崖
来自互联网公司技术高管的亲身经历与感悟
再次创业维艰,没有什么公司能一直都是一帆风顺的,会面对各种各样失败、还有逆境,如何激励员工一如既往的使命必达,这也非常非常的难。经历过回想起来还是能够体会技术一号位在创业公司操盘技术的不容易。
文化理念冲突,所有你在大厂认为理所当然的事情,在这里不复存在了,你要解决认知落差的问题。
一线普通员工不会轻信大厂光环,也不会相信江湖传说的,技术员工特有的小傲娇肯定私底下会议论:“不就是大厂待过嘛,级别比较高而已,高P都不干活的,大厂高P都是PPT选手,肯定只会瞎忽悠,我们就看他能瞎指挥,看笑话吧”,所以你特别需要获得一线员工信任的问题。
新的老板来了,中层管理者人人自危,深怕自己做错丁点事情,最后换的被血洗的下场,大家都藏着掖着不肯暴露团队问题,大家都只会报喜不报忧,最后你可能连一句真话都听不到,所以你也特别需要取得中层管理者的信任。
老板和同僚对你一定会期望过高,需要你立刻马上给组织带来新气象,让大家如沐春风,稳坐钓鱼台。而此时的你可能甚至连业务细节还不知道,面对每次会议提到的专属名词还一脸懵逼,甚至在每次老板的会议上被问到技术有没有问题的时候,你只能硬着头皮说没问题,实际上你压根不知道有没有问题,心里其实慌得一比。
好在面对压力我没有放弃(玩笑),反而快速调整状态寻找到应对策略,其实上述问题最后可以被解决就是要做好关键几件事。
空降技术高管如何在深度和广度上
取得一线技术人员信任?
如何做到以技服人?
空降技术高管总是认为自己是带着光环而来,以为有这个所谓公司授予的title就能很好的管理团队,殊不知依靠title的管理只是行政上的管理,这在管理上来讲是最低效的方式,而靠影响力建立的心智管理才是高效的。如何做到获得团队认可,如果说一定有捷径的话,那就是先让自己融入到团队中去,那到底如何融入呢?有个词说的特别好,那就是“躬身入局”,躬身=谦卑,入局=泡在一起,简单来说就是带着欣赏的眼光,空杯的心态和你的伙伴混在一起吧。
是的,每个技术高管一定是有自己两把刷子的,但是无论你曾经有多少经验和积累,和你的伙伴泡在一起的时候,也请保持开放性和兼容性,每个人都是独一无二的,对方肯定有他具备优势的地方,所以应该把自己的经验和经历放一放,多花点时间了解当下的环境和团队,带着欣赏的眼光看待他们做的事情,不要认为和大厂做法有差异就一定有问题,一定不能有这样偏见性的假设,等了解事情的真相后再看有什么问题,同时思考自己如何中肯的提出建议给予帮助。
另外千万别靠你的下属给你做象征性的汇报就能找到切入点,我认为最好的解法就是知行合一,参与到实际的各个产研线的产品&技术评审中去,去倾听最真实的现场声音,只有这样你才可能从业务场景、产品设计、技术架构、质量保障、线上稳定性、成本可控等多个方面了解团队现状和问题是什么。
大厂背景的技术管理者有个最大的误区就是总是经验之谈,大厂因为体系较为成熟各个方面都是总是走在技术前沿,而大厂待久的管理者因为看得多,听的多,最喜欢说的口头禅是这个事情很简单,阿里、腾讯我们是怎么解决这个问题的,完全不顾团队当前所处阶段,立马提出一些不切实际的技术目标,让伙伴们吭哧吭哧的调转车头火力全开的复制大厂的方案。
但如此激进的推动手术刀式的技术变革,可能实际是远在当前团队能力承载之上,很可能最后的结果是这个技术项目根本推动落地不了,还弄得个怨声载道,叫苦连天。
当然技术改革绝对不是一件坏事,关键看如何实施的问题,我个人比较推荐的做法是将自己在大厂沉淀的前沿技术方向通过学习分享会的方式分享给一线伙伴,待他们理解消化后,再根据团队实际能力再去定个半年、一年、甚至两年的OKR计划进行推动。
以我个人实际经历的案例来说,我当时看到的最大瓶颈问题就是系统迭代发布问题,当时大家发布的流程非常传统,整体上基本停留在纯人工的研发和运维对接,经由运维PE检查代码版本和相关配置项版本是否正确,然后进行手工脚本的方式进行线上服务器代码部署,每个发布过程可能耗时半天到一天,19年大概100多人的业务研发团队,一个月只能发布30-40次,迭代效率极其低下。
解决这个问题,我的做法是首先准备了相关技术材料,跟伙伴们分享了业内DevOps的研发模式的优势,并介绍了相关技术产品实现细节,并提出了从需求-研发-测试-发布-运维全流程一体化研发效能可度量的技术愿景,通过想法提出到细节设计再到组建团队跟进,前后经过1年多时间的打磨,最后标志着我们公司研发方法论的研发效能DevOps平台-琉璃塔产品新鲜出炉,该平台直接让我们研发效能从过去一个月不到百次的发布提升到了将近万余次,代表着我们研发效能有了质的突破。
当然发布线上化,研发过程可度量还只是开始,对系统稳定性的保障,对多环境的隔离治理,对机器资源的利用率保证等等事情,便是接下来这个方向我们要持续探索的事情,关于这块我会在纯技术栏目跟大家分享我们的进展。所以任何看上去特别美好的事情,如果不去评估团队当前阶段,不从实际出发,而只是为了迎合管理者个人技术喜好的话,很可能好方案也可能变成烂尾房,最后它永远可能就是诗跟远方,可远观而不可亵玩。
另外因为公司发展太快,很多需求都涉及到全链路从业务到产品,再到研发、测试、交付、运营多个团队的协作,但因为项目范围太广,对外对内的业务细节,技术细节错综复杂,同时还要协同外部部门多方角色进行工作,所以经常出现延期交付的情况,而产品研发团队通常是这些项目中主要参与者,所以理所当然成为了众矢之的。
一般人都不敢接这烫手的山芋,但我却认为是落地成功最好的切入点,做对外对内的衔接角色,自己亲自作为PM的角色参与到一个重大项目中来,并推动上下游,形成合力,将自己项目管理能力进行经验复制,在较高复杂度或者跨多个职能部门项目(链路较长、模块复杂度较高、复杂度较高、发布周期较紧、风险较大、技术驱动)的项目保质保量的交付,获得各方的一致好评,这就是对你个人能力呈现,建立公司级体感影响力的机会,也是标志你落地成功的最好证明。
记得刚加入公司最令人沮丧的就是故障频繁,因为业务的特殊性,晚上凌晨后是某些系统的高峰期,而恰巧这些系统是稳定性短板。可以这么形容,近半年的时间每晚都是提心吊胆,生怕接到了业务一号位或者老板的电话,因为一旦看到那个熟悉的又爱又恨的号码的时候,我就知道我应该拉电话会议解决线上问题了。其实故障出现了不可怕,可怕的是你把你自己当作局外人,之后还趾高气昂的一顿责骂。人不可能不出问题,特别还是一个技术薄弱的创业公司,所以现阶段你一定要认为故障是常态。
而作为技术一号位我觉得不应该只会站在局外进行抱怨和责难,而是应该和团队共同面对困境,一起承担外部对研发的质疑,同时更要帮助团队快速定位和解决问题,一定要亲自参与到线上故障问题诊断的现场中来,带领相关团队快速诊断问题,恢复线上故障。在这里我一般的做法一定要全面熟悉相关系统的技术架构方案,充分了解业务流、资金流、数据流三流的扭转流程,对故障系统的上下游系统的依赖关系能够具备清晰的感知和理解。
如果全方位了解的话一般而言,线上的故障现象一定能第一直觉就能知道是哪个系统代码模块出现问题,所以你在组织故障排查会议的时候,能够快速的安排故障恢复执行步骤。当然,事后故障排查你再厉害,也比不上通过做在事前减少故障发生概率的价值,所以稳定性建设才是杜绝业务损害的唯一选择。关于稳定性建设本身是一个非常大的话题,我后面会有专门的文章来介绍。
到目前为止,我仍然认为作为一名优秀的技术管理者一定是具备三位一体的能力:“懂技术、懂业务、懂管理”,但技术深度是所有事情的前提,也更是做好人员管理的前提,这也是我用人的一个基本标准,对自己的要求也是一定不能脱离技术空谈管理和业务,所以技术管理没有纯管理角色,一定是以技服人,方能做好管理。
落地过程中快速取得创业公司技术管理老人的信任
先不论这样的做法是否真的有利于团队迭代升级,但可以想象的一点是人心肯定是受到伤害了,正所谓人心散了,队伍就不好带。关于这点,我特别佩服伟大领袖毛主席,他老人家在抗战艰难阶段始终走的是群众路线,而且非常善于团结一切可以团结的力量进行革命斗争。
所以回顾历史都会是一本好的参考书,作为空降的管理者,你如果只会制造阶级矛盾,而不会团结一切可以团结的力量,很可能在落地过程中会遇到很多意想不到的麻烦,最显而易见的就是没人愿意跟你讲真话,因为没有了信任链接,所以你始终都是局外人。
那如何建立信任,我觉得也很简单,就是针对性的帮助对方解决问题。以我个人经历为例,要以社区工作者解决社区居民问题一样,挨家挨户的替他们分忧解难,我的做法是第一步找每个人进行深聊,把他们的困惑、疑虑和需要我协助的事项都给聊透,并承诺给他们解决问题的时间,如果是时间跨度较长的疑难杂症,还要记得给当事人做阶段性的反馈。
举个典型例子来说明,当时我的部门其中一个中层团队管理者,因为技术视野问题遇到了发展瓶颈,在我深入调研后,发现需要整个团队进行角色认知改变和工作内容转型,才可能跟上公司的发展节奏,而且这个转型不加快,很可能面临汰换的结局。所以当下你有2个选择,要不找人另起独灶,让其自生自灭,要不携手一起战斗帮助其完成转型,当然我选择了后者。
具体的做法是协同这位管理者一起跟全员宣导行业的发展趋势,同时从研发这边研发效能现状出发定位问题,从而引导出当下团队马上可改善的挑战空间。当然也需要引申下行业前沿的诗跟远方,最后不忘记给予信心支持:“如果大家能够不畏困难,敢于挑战,一定可以取得突破”。
此外具体的行动支持才是尤为重要,首先该做组织架构调整的做组织架构调整,该协助招人的帮助招人,该参与核心产品和技术方案评审的一定要参与,所有的细节都要把控好,保障这个项目万无一失的完成。
只有和伙伴们在一起经历过一场硬战和胜战,那么你和中层管理者稳固的信任关系自然而然就建立了。所以无论如何信任是领导力的前提,没有信任根本就谈不上领导力,没有领导力更谈不上做好管理带好将。
找到合适的同路人
团结一切可以团结的力量,不代表就可以不引入优秀的管理人才了,公司在高速发展,优秀的候选人是支持事业持续高速发展的前提。此外,创业公司不管怎么说人才厚度肯定很差,即便你如何欣赏对方的优点,总会有一些伙伴的成长跟不上公司发展的节奏,需要被汰换或者转岗。
所以你一定要去寻找更加优秀的人才加入团队,但到底招什么样的人会比较关键,很多人其实最容易在招聘高P的过程中犯错,我也不意外。在这个方面至少栽过三个跟头,而找错人的破坏力真的很大,结果也真的很痛。
现在反思之前招聘技术高级管理者犯过的错主要就是只考察了技术专业能力,而缺少考察候选人另外三个关键维度:
(1)创业初心
候选人加入创业公司的初心非常重要,他到底是为了实现事业跃迁带来的自我实现,还是只是为走捷径,赌一把短期上市后,期权能带来丰厚的物质收益。
当然我们不能只谈理想,不谈现实,但如果一个人加入创业公司,只是看公司能不能短期上市,看手上的期权能不能兑现的时候,可以肯定的是他的稳定性和付出程度,完全是跟公司是在顺境还是逆境有关,一旦预期收益不达预期,必定会有很多负能量和抱怨公司行为产生。而且如果他还身处要职,这些行为必定给团队造成巨大的伤害,所以创业公司核心岗位的招聘,一定要考察候选人加入的初心。
创业维艰,没有哪家公司在发展过程中能一帆风顺,这期间一定会经历挫折、不断的失败、甚至生死,所以那些没有长期主义,不能站得高,看得远,没有定力,只希望投机取巧,投机倒把的人,很难一路艰辛伴随公司走的长远。
所以即使他能力很强,也要慎重选择。创业阶段你要找能真正相信你,相信这份事业的人,要找看的远、发的狠、钻的透,忍的住的人,这些人是真正看懂底层逻辑,并有着非凡的定力,一定是大智若愚的人,因为创业就是一群疯子带着一群傻子不计得失的往前冲,只有这种韧性的人才能带着事业走到远方。
(2)文化适应度
很多聚焦传统行业的创业公司,可能都不是互联网背景的老板,所以整个公司文化,也可能跟互联网行业习以为常的东西大相径庭。比如传统企业公司绩效文化,会认为所有的员工是劳动密集型,需要有严控的管理制度管理,认为工作时长越长,产出可能就越多,员工即使离开,我也很容易进行替补。
但互联网文化的绩效文化会是认为我们是脑力劳动者,要自由创造的工作环境,创新和结果才是衡量价值的标准。所以很多互联网从业者加入传统公司后的工作感受就会觉得如坐针毡,因为工作方式,周遭环境、所见所闻都让自己觉得无法理解。
面对这种情况,我的观点是很难改变公司,那就只能改变自己。首先清楚知道自己想要什么,只要主航道上并不存在不可调和的矛盾,那一切都应该要去适应,所以招人也是一样,一定要招文化耐受度较高的人,而且招聘环节一定要设计专门的问题考察对方的文化耐受度,同时建议在招聘环节比较坦诚的讲清楚自身公司的文化现状,不能藏着掖着的忽悠对方入职,坦诚面对才能换来真心对待,否则最坏的结果是候选人来了之后发现适应不了新公司文化,落地过程中怨声载道,负能量爆棚,最终半年内一拍两散,公司赔了巨额的猎头费不说,还让团队一线员工受到一次组织震荡的伤害。
(3)个性和品德
对于创业公司而言相对于个人能力优不优秀,我觉得人的品德更加重要,在这点上我曾经犯过严重的错误。
当时因为一个团队急需一名技术管理者,我们通过猎头接触到一名阿里的高P,因为时间有限,我只跟他沟通了技术相关的问题,面试下来感觉技术上还不错,也做过很多比较有挑战的项目,但隐约感觉人有点固执,脾气略显急躁,但考虑技术人员总有点自己的小傲娇也正常,只要技术上能服众就OK,所以就给了Offer,但是后面没想到在背调的时候出了问题,就是背调人信息作假,相关背调的团队建议不录用,当时我考虑用人之迫切,我们创业公司招人之难,我顶着压力跟候选人沟通了为什么会提供虚假信息,总之他给我了一系列看是合情合理的理由,我也没多想太多,顶着压力依然录用了这位候选人。
但接下来的事情果不其然啪啪的打了自己的脸,你在面试过程中所担心的所有问题,如个性、脾气,诚信等一系列问题,在他来之后的工作中一一被应验,还因是一名管理者,造成的杀伤力是Double的。
经历过这个事情后,我深刻的反思:情愿这个团队没人带,由我直接带,也不要因为急缺职位而放低标准去招人,也不要因为创业公司难招人而放低标准招人,因为你在面试中所发现候选人的小问题,一定会在接下来的日子里面被无限放大,并一一应验,你可能要花费巨大代价才可能消除这个麻烦。
尽快落地几件有体感的大事
创业公司之所以要引入技术高管,一定是因为技术板块已经跟不上业务发展的诉求了,一般而言人和事都有问题,其特征主要表现在:
线上经常不稳定,如流量大了系统承受不了,经常宕机,或者线上经常有BUG,影响用户体验。
研发迭代效能跟不上,业务期望一周能上线的功能,研发团队评估至少需要三周才能上线。
没有技术前瞻性布局,面对业务发展,都是见招拆招,应对业务要求越来越吃力。
研发人员战斗力不行,士气涣散,把自己定位成资源,做事情没有自驱力,按部就班,得过且过。
此外团队内部文化不正,内部存在山头主义,部门墙高耸,存在人事斗争。
虽然面对创业公司较差的技术现状,但是周边部门包括不懂技术的老板,是丝毫不理解要解决上述问题的困难程度,他们指望着技术高管立马能解决目前技术拖后腿的现状,但实际上面临问题实在太多,神仙也没办法立马全部解决,各种酸爽只有自己知道。
另外创业公司一般都是业务优先,业务驱动发展,所以技术的价值被肯定绝对不是自嗨,你的价值一定需要你的用户和受众来肯定和评价,所以如何为业务创造有体感的价值那就是最重要的事情。我认为只有躬身入局亲自带队解决掉解决2-3件对内外部都有体感的大事是为上策。
基于此我盘了当时最重要的三件大事:
公司战略型的大项目作为主要推动人,在较短时间内保质保量进行交付。
设计贴切公司当下业务,并立足于未来的产研组织架构。
推动管理三板斧:职位职级、晋升体系、OKR绩效管理。
第一件事主要目的是作为战略项目的内外衔接和推动者,能较快建立研发在公司级的正向影响力,一定程度上减少技术过去拖后腿的固有印象。
第二件事主要目的是让公司核心业务部门的需求能有独立组织单元去进行承接,同时设计立足未来能够实现共性需求下沉的平台产品和中台系统的组织架构。
满足能在未来能贴切业务更加快速响应业务需求,快速承接需求快速迭代产品的同时降低研发投入成本。
第三件大事目的就是通过管理机制建立可量化的成长模型,促使员工过去资源认知到自我成长迭代认知的转变。
喜欢巴结新来的高阶管理者,不断通过拍马屁取得管理者的信任,表忠心,证明自己已经站好队,愿意鞍前马后为之效劳; 非常喜欢拉拢身边伙伴分享所谓的团队、公司内负能量的小道消息,时时刻刻彰显小团伙文化; 人浮于事,所有的精力都花在人事斗争的谨小慎微上,比如生怕组织调查,打着辅导员工名号,每天一对一找自己团队成员交流,实则威胁员工不要讲真话; 团队管理好大喜功,管理上一碗水端不平,不听自己话的员工想尽一切办法边缘化,员工敢怒不敢言,团队内部氛围极差; 和身边同事沟通还是和自己老板沟通交流,想尽一切办法截图和录音保留证据,以防后面出现对他不利的事态发生。
与这些人斗智斗勇的过程中,如果没有一个善于思辨的头脑,可能真的容易被这些“聪明人”玩弄在股掌之中,所以面对这些文化不正的员工,不要被表面现象迷糊,虽然说不放过一个坏人,但也不能错怪任何一个好人。所以一定要花点时间洞察清楚,不要急于动作,保持耐心等待坏人露出马脚,收集足够多的证据,然后再一举拿下。
可以理解的是,新的管理者刚上任就开始开人其实是件特别不容易的事情,第一,当心被别人讲闲话,说自己排除异己。第二,中国人都与人为善,有时候不太愿意直面人事冲突,倾向于忍让。第三,中国人大多讲情面,喜欢讲治病救人,心想此人还可以影响影响,还可以改变改变,改变后还是位好同志。
但是实际上我想说,但凡出现触犯红线品行不端尤其是不认可团队价值观的同学,会把一些负面情绪、行为影响到团队其他同学,而且这无关能力,能力可以培养,经验可以通过工作进行增长,但人的品格和性格是不可能因为你有高超管理手段而彻底改变的。因此面对这种员工一定需要杀伐决断,当机立断采用合适的方法让这类员工离开。
最后以一句我经常和团队分享的话来结束本文:“直面挑战者,躬身入局者,皆为我辈”,以期与之共勉。
本文经授权转载公众号思辨致知(gh_66c6f63fe6b7)