新人经过打基础积累经验,通过做项目成长为出活的中坚力量,到此为止都有比较清晰的发展方向。再往后,最重要的就是培养自己的主人翁意识ownership。
做优先级高的项目,不怕失败
有时候,你很难去判断一个项目到底是机会还是坑。当一个项目摆在你面前的时候,你要做的是了解这个项目的优先级和visibility,然后才是可行性和风险等等。如果一个项目是公司的最高级别,我认为不管风险多大你都要上。这里说的“你”已经不再是个新人,不需要通过积累成功的项目来证明自己是个可靠的IC,而是要担起责任。因为能力越大,责任越大,责任越大,风险也越大。
最高级别且有很高visibility的项目会得到公司从上到下的有力支持,你所遇到的所有技术、组织架构、资源需求都会最大地被满足,也能够最大限度地进行跨组合作和协调。一个高级别的项目通常会有多方的stakeholder和负责人,你作为一个IC,不可能是单打独斗,会有很多其他IC和manager一起推进项目。遇到这种项目,不要怂,主动跟老板请缨,不管是staff成为项目的lead还是senior成为参与项目的小兵。不要老想着项目失败了怎么办,不要怀疑自己的能力,更不要瞻前顾后地想着回去做那些自己已经驾轻就熟的日常小活。
你要站在主人翁的角度去想,如果这是你的公司,一方面需要日常维护,另一方面也需要冲锋陷阵。日常维护能让你的公司维持现状,操作起来没什么风险,但是只有不断创新才能让你的公司在不断的市场竞争中保持领先。创新的项目一般风险高,但收益也高。上前线冲锋陷阵风险大,但立功的机会也多。打工人在公司做项目的风险,相比于上前线打仗,基本为零。最坏的结果,就是项目失败。除了极少数情况(一个产品失败,导致整个组被砍),大多数时候,项目失败对打工人个人的影响基本没有。工资照发,已经有的跨组合作经历和visibility一个没少,贡献和leadership也都可以写在升职报告和年终评审中。无非是最后因为自己不可控的原因,项目失败。这些失败的项目,就跟失败的startup一样,对创业者本身的好处大于坏处。因为好的项目好的公司,很多时候无法避免会有很多不确定性和高风险。而你作为一个IC,能够把自己推出去,成为大家信赖的技术骨干,这件事本身就是赢了。当然项目能做成功,那就是赢大了。
我们常说失败是成功之母,但工作之后,很难避免地会害怕失败。最后想举两个例子,来说明失败和事故没有想象的那么严重。
我之前的一个项目,想要看模型在不同数据量下的表现,我的假设是随着数据量的增加,模型的AUC会提高,在到达某个数据量之后,再提高数据量,AUC的提升就不太明显了。这算是个很经典的模型训练问题,道理简单,操作也并不困难,主要难度在于自动改变模型训练的数据量,进行多轮训练。平时训练production model,大概也就是一周一次的训练频率,而我这个实验,一天之内训练了几十次。我所在的公司当时用的是Google Cloud Platform,按照运算力收费,我事先并没有考虑费用的问题。当第二天我从老板那里得知我这个实验花了两万美元的时候,我正开心地处理实验数据。老板、组里其他的人、大老板、隔壁组的人都跟我说没事,费用不是问题,主要是reporting那边不知道我在跑实验,看到费用突然大增还以为出了什么事。尽管如此,我还是很不安,担心公司因为这个把我开除了,毕竟对于startup,两万也不是小数。而且从return on investment来看,我这个实验似乎也没什么实质的return,因为实验的结论是,我们现有的训练量足够了,再减少50%对AUC也没什么影响,但是为了保守起见,我们还是维持原状。这件事之后,我没有受到任何处罚,也没有人找我谈话,这件事最后成了大家经常来开玩笑的段子。不过也因为这个事情,以后每次在Google Cloud Platform上跑实验前,都会做一个费用的estimate或者跟老板打一声招呼,以防出现这种突发的费用暴增,从流程上去减少可能存在的意外情况。
广告优化的模型直接关联公司的广告收入,所以每次有incident都是很高级别。这么重要的系统,人为的错误也是不可避免的。在deploy new feature或者改数据库的时候,因为“不小心”或者“没想到”的原因,导致系统崩溃,公司也会损失很多钱。想要系统不崩,除非什么new feature都不加,用的其他库的version都不变。但这明显是不可能的。要想做更好的系统,就必须得加new feature,加new feature就有风险,就连照理说没什么风险的refactoring都不能避免搞崩。公司的一个理念就是fail fast, learn fast。我们组开组会的时候,大家也会经常分享自己的failure。有几次的incident,我都觉得搞砸的人要被开了,结果也什么事都没有,也没人blame,大家都是出现问题解决问题,然后从过程和ways of working上减少人为错误的可能。毕竟,是个人都会犯错。除非你是故意搞破坏,我工作至今还没有看到因为过失failure而被批评或者开除的人。
主动创造机会,不要坐等许可
随着你经验的积累和级别的提高,更多时候,项目和机会是要靠自己去发掘创造的。我们常说机会是给有准备的人,这句话的另一层含义是说,有准备的人能够发现别人看不到的机会。
IC的职业发展,会强调技术领导力tech leadership。这个不仅是在公司已经存在的项目上冲锋陷阵,还要自己去开疆破土,去创造新的项目和initiative。如果只是等着公司上层的安排,等着老板的指令,指哪儿打哪儿,那你就很难展现领导力,只是一个听话能干的人。
有主人翁意识的打工人,会时刻去观察思考公司有哪方面不足需要提高,有哪些产品feature是可以添加的,有什么环节还可以优化,有什么新项目可以做。试想,如果你是你们组的老板,是你们部门的engineering director,是你们公司的CTO,你觉得公司下个季度应该做什么?公司现在的组织架构是不是能够满足不同部门之间技术上的有效合作,如果不能,要如何改善?公司现在的tech interview流程是不是最好的,如果不是,要如何改进?公司现在的产品是不是能够满足用户的需求,如果不是,那么缺口是什么,能不能填补,怎样填补?竞争的公司也推出了相似的产品,他们是否对我们构成威胁,我们要怎样才能保持领先?
这些思考并不是自己一个人坐着干想出来的。
第一,关注公司的季报、年报、各种公司内部的战略报告、产品roadmap等等商业的讯息,关注市场和竞争者的近况,了解公司的组织架构。
第二,多跟产品经理PM聊天,可以从自己组里的PM开始进行1on1,是biweekly或者monthly,从他们那里了解部门的产品规划,PM经常会知道一些产品roadmap的PPT,如果你不去问他们,作为IC一般看不到这些PPT。随着你工作宽度的提高,也可以跟合作组的PM聊天,了解不同组的产品规划和需求,特别是他们目前的痛点,看是否有跨组合作的可能。PM会站在公司商业的层面和用户需求的层面,给你不一样的视角。
第三,跟公司不同部门的IC聊天,有人把这个笼统地成为networking,但我觉得应该叫做informational interview。怎么认识不同部门的人呢?1. 你加入公司的时候参加入职培训和bootcamp,一般都会有很多不同部门的人一起,这时候培养起的新人情谊,我个人觉得是非常深厚的。很多我入职时认识的人,之后很长时间都没有持续联系,但是当我需要从他们部门了解一些信息的时候,我都能很快地联系上他们。2. 公司各种社交活动认识的陌生人,这些联系人一般要在工作一段时间之后才能比较容易聊上天,刚加入公司你自己都还没熟悉项目,也没有太多能够分享的。而工作一两年之后,再跟其他部门的人聊天,总是会有很多共同话题作为切入点。3.作报告的人。公司经常会有很多公开报告,不同部门的人都会讲。如果你对某一个话题感兴趣,就可以直接联系作报告的人,不管是在slack上问问题,还是约1on1,都是了解其他部门的机会。4. 到处问ask around。比如我作为广告组的人,想要了解音乐组的人是如何推荐音乐的,如果我不知道问谁,我一般会在组里的slack channel,公司的slack channel,以及各种杂七杂八的slack channel发问,一般都会得到答案。
获取的信息越多,越能够触类旁通,也能够发现大家共同的痛点和unmet need,而这些通常是新机会的突破点。这些机会,如果你不主动proactive寻找,是很难发现的。
发现这些机会之后,就可以把自己的想法整理成RFC (proposal),跟不同的人聊项目的可行性和重要性,搜集反馈意见。可以是资深的同事、mentor、PM、其他部门的同事。在写RFC期间,要及时给老板进展的汇报,讨论项目优先级,问老板如何才能更好地继续这个项目。如果是跨组的initiative,通常在写正式的RFC之前,你要组织大家开会,可以是brainstorm、working group、kickoff之类的会议,主要目的是广而告之自己要lead这个项目,提高项目和自己的visibility。在RFC成型之后,就可以正式分享给老板、PM、组里的大老板、和各路相关的stakeholder,然后就到最关键的一步,说服决策者优先你的项目, prioritize your oroject。很小的项目比如tech debt,可以加入下一个sprint planning里;小项目可以说服老板和PM作为自己当前季度的side project;中型的项目一般会加入到下个季度的OKR里,有多个IC一起做,你作为项目lead参与项目实现;而大型项目一般会加入到多个季度甚至年度的roadmap和OKR里,这些项目大多都是多组合作,你作为项目的提出人,有可能并不会参与到项目实现implementation,而是更多地参与项目的协调、跨组的沟通之中。
IC的领导力,在于推动公司的OKR和战略,而不仅仅是完成分配的工作。
刚工作那会,我完全没有主人翁的概念,总是依赖着组里的大牛、senior和老板给我派活。很多活都是短平快,目标明确,时间线清晰,大概怎么做我心里也有数。过了一段时间,我熟悉业务之后,开始有了自己的一些想法和想要钻研探索的方向,开始写proposal和项目计划,做demo和prototype,直到这步都还很顺利,我也逐渐积累了很多不错的初期结果。但再往下我就不知道怎么推进了。现在想想,项目从proposal到roadmap之间是质的飞跃,不仅需要技术能力,还需要说服力和领导力,以及不怕失败的勇气和敢为人先的精神。
有时候,我们要推自己一把。我之前自己写RFC经常会瞻前顾后,各种优劣考虑得过于周全,以至于无法说服自己做决定。我的犹豫不决也反映到了RFC的写法上,自己没有明确的提议,而是列出各种alternative,然后希望读者帮我做决定。这是没有主人翁意识的体现:我潜意识里不想自己做决定,承担决定的后果,害怕自己的决定会失败,而是依赖别人帮我做决定,如果最后失败了,就不是我一个人的错。而有主人翁意识的人,会把决定权掌握在自己手中,其他人对自己只是辅助咨询的角色。还是以RFC为例,我现在就会写明自己决定的方案,其他人可以提意见,我也可以改方案,但是最终的决定权还是在我。
我的一个mentor曾经说,it’s better to ask forgiveness than permission。这句话对我的影响深远。他鼓励我要主动出击,不要等着别人来帮我做决定,也不要等着所谓的许可和指令,要自己掌舵,自己做决定。如果失败了,那就own it。
性别差异
作为女性,我从小就经常听大人说,女孩要乖,要听话,要干净。男孩就是淘气,皮,不听话。耳濡目染之下,很多女性,包括我自己,都会习惯于听话,坐等许可,等着别人给自己发号施令,过于注重细节,保持“干净”,害怕失败出丑,脸皮薄。而很多男性则是敢闯敢拼,不拘小节,不怕失败。因为差异的性别教育,主人翁意识很容易跟男性气质挂钩。一个女性,如果表现出强烈的主人翁意识,敢闯敢拼,不坐等许可,会被视为aggressive、bossy、push、脾气不好、不够“女人”。很多公司都已经意识到这些对于职场女性的偏见,有很多培训项目去破除这种偏见,帮助女性提升领导力。
作为职场女性,我们要培养自己的主人翁意识,第一,要意识到很多时候自己的想法和性格并不是先天的,而是受到文化的影响。第二,要有勇气,敢于冲破这些文化和教育的牢笼,敢为人先。第三,要相信自己,相信自己的能力和判断,把决定权掌握在自己手中,打破依赖心理。第四,不怕失败,要有韧性resilience,脸皮要厚。最后,要建立自己的support network。没有一个英雄是单打独斗,没有一个主人翁是孤立无援。
写得真好 ,受益匪浅。感谢分享
在这一个周一的早晨 很幸运读到了你的文章
写的很赞,入职一年了我还是大部分时候等派活
受益匪浅!
真的很棒!同为女孩子学到了很多,一起加油!