原文地址:研发leader成长手册(一)研发Leader成长手册(二)研发Leader成长手册(三)

近来和一些担任研发leader的同事和朋友交流中,发现部分同学,在研发leader的岗位工作上遇到了瓶颈。具体的问题,有个人发展空间上的,有工作内容上的,有时间精力安排的,有对外合作配合的,笔者仅以自己过去的经历和对leader工作的理解,分享一下对成为一个成功的研发leader的视角、观点。

研发leader的工作内容,可以分为以下几个方向:

  1. 技术方向工作
  2. 规划方向工作(目标、计划、执行、制度等)
  3. 协调方向工作(跨部门沟通、跨部门项目协作)
  4. 团队方向工作(招聘、培养、沟通、团建、宣传等)

在这几个方向上,分4个主题,逐个来分析、探讨。这4点交融在leader的工作中,因此每个方向探讨时,会有互相交叉的部分。

# 技术方向篇

在技术工作方向上,容易出现的三个误区:

  • A. 技术leader是团队的产出核心,其他人辅助工作
  • B. “我”是做技术的,产品、运营做的好不好,不关我事
  • C. “他们”技术不行,培养太花时间,等他们做完,我早做完了

下面我们来刨析这三个误区,看看这么做leader工作会带来什么问题。

# 01.技术leader是团队的产出核心,其他人辅助工作

作为研发团队的leader,首先要做好技术方向的工作,这是这个岗位的最基本职责;大部分研发团队的leader,都是因为技术工作做的比较好,而被提拔为leader,给予晋升空间和发展空间。但是技术leader的职责不仅仅是技术方向的工作,还要承接更多的岗位职责,大部分leader感到工作瓶颈,都是在非技术工作上面。

在技术方向的工作职责之外,其他的职责,是初晋升研发leader所不了解、不擅长的,此时如果没有得到很好的帮助或自己思考想清楚,工作便会出现一个迷茫期,不仅影响自己的发展,也影响团队的整体产出。笔者也未幸免,曾经在非技术方面折腾过一段时间,深为苦恼,甚至怀疑自己是不是应该回去做技术专家,而不是去带技术团队。

我从这个坑里爬出来,最直接、最重要的一个因素,是意识到了研发leader的岗位职责变化。研发Leader的岗位职责是要看团队整体的产出效率,而不是看个人的产出效率。作为曾经的研发好手,在技术问题攻关、代码编写质量、速度方面,是自己的长项,晋升leader也是因为这些方面的强项,被公司、上级所认可。这会给晋升的leader们一种错觉,技术能力和项目产出是自己的主要贡献。

在这种“leader观”下,会不幸的形成以自己为技术中心、其他团队成员协助工作的模式;项目里最难、最重要的部分,由leader攻关、实施;leader成为团队最忙、负载最大的同学。这种情况在早期阶段,依然可以运转一段时间,但是随着时间的推移,因为leader其它工作职责的加入,把leader已经被技术工作占满的时间、精力,轻易的给“引爆”。

团队成员遇到了工作的问题、招聘面试量的增加、和PM沟通讨论产品方案、和业务方开会讨论需求、开展晋升绩效的沟通、团队工作汇报的准备等等,会迅速的开始消耗leader的时间精力,使得leader主导的技术攻关、项目攻关,出现延期、失败,而团队其他人由于技术能力问题、分工安排问题,不能有效支持项目推进。此时,Leader不得不面对这个现状,为了摆脱这个“陷阱”,做出选择。

  • A. 拒绝技术工作外的管理工作,来保障技术工作的完成;
  • B. 投入时间做好管理工作,但技术工作陷入混乱;
  • C. 对管理工作敷衍,依然把主要精力放在技术工作上,保障技术工作的完成。

笔者当年走过由A到C,再到B的过程,所以在今天的工作里,对团队里的技术leader,非常能够理解他们遇到的工作上的问题。下面我说一下我自己的经历。

刚开始,我对自己被提拔为技术leader非常兴奋。作为一个疯狂的技术爱好者,这种晋升,我认为是对技术能力和产出的一个认可,非常有成就感。我把这次晋升,当成了一个奖励,丝毫没有意识到随岗位的变化,我的职责也变了(当然也没有人真正严肃的对我说,我的职责变了,要求的能力模型变了)。也丝毫没有意识到,除了技术能力,其他方面我都没有达到一个leader的能力要求,处于“不知道自己不知道”的状态。于是更以加倍的热情,投入到开发工作里,绝大部分时间都是在做开发,少部分时间分下任务给团队其他人。

由于是团队leader,HR开始安排更多的面试工作,自己部门的、其他部门的,在面试工作的时间上,基本增加了一倍以上;项目经理、客户(内部需求方和外部客户)开始找我沟通项目的安排、进度,会议的量开始增加…… 是的,各位leader今天遇到的问题,我也没意外的遇到了。我热爱技术工作,我是技术极客,干嘛让我把时间花到这些“虚”(不是写代码,都是虚的)的事情上呢?I reject!

但是拒绝不了多久,就被我的老板谈话了。这些事我不参加、不做,对应的伙伴们,自然就要找我的老板投诉了。当然这也不难沟通,作为leader那些事是要做的,只是我不喜欢,那如果还要做leader的话,就得改变自己啊!价值观是杠杠的,调整自己认真对待技术以外应该承担的工作。但是我的精力客观上是有限的,白天用了40%-50%的时间在这些问题上,技术工作就只能继续用自己的夜晚时间来补充。熬夜到12点后,成为一个常态。【曾经有一回,在公司加班到1点,开车回家的路上,我睡着了…着了…了,以60KMPH的速度,撞在了前面一辆现代SUV上,还好相对速度不那么大,车损人未损。阿弥陀佛,如果不撞上这辆车,我撞上的,将是50米前方的两个水泥路障,当时在施工建设地铁,阿弥陀佛,救命之恩!】

好吧,知道不能这么下去了,我在认认真真的想,我是不是该回去做程序员?我是不是根本就不适合做管理? 在这种不坚定、不明确的状态下,对非技术类的工作,进入一种敷衍的状态,开会时经常两个耳朵听着,两只手在看着屏幕敲代码…… 不知道当时的同事们有多想骂我,在此对你们说声sorry!然而我一直没有下定决心往回撤。因为人都要上进,没干好的情况下往回撤退,我岂不是懦夫。隐隐的感觉到,我自己遇到了“瓶颈”,我需要突破自己。也就是说,进入了“知道自己不知道”的状态。

转机出现在一次去广州出差的路上,在机场买了一本《领导阶梯》,完全是偶然的在机场买了一本。里面明确说明了一点,作为首次晋升的leader,根本的转变,是我从个人贡献者,转变为一个管理者。两者的差异,在于职责上,Leader要对团队的结果负责,而不是对Leader自己在其中的比例负责。 进一步,我做了以下的思考。

假如我们团队有6个人,我个人超强,一个人贡献团队40%的产出;其他人平均每人贡献12%的产出(合计算100%);假如我通过管理工作,让团队的外部环境井然有序、任务明确,并致力于指导、提高团队成员的能力,让每个人的产出,提升一倍,我自己的个人贡献因精力转移降低60%,降到16%;此时我们相对以前,整体的产出是 (16% + 24%*5)= 136%。这样,我做为leader的杠杆效用,就出现了:通过我的工作,团队的整体产出增加了。

懂得这个逻辑无比的重要,能让自己下定决心转型,做好外部工作,做好内部指导、培养工作,通过自己的工作提高团队的整体产出,给团队每个人带来成长。对leader的考核,应该是团队的整体产出情况,而不是leader个人做了那些具体的事。

因此,技术leader在技术工作上,应该把精力转移到那些体现leader价值、高杠杆率的事情上。包括:

  1. 和产品经理或项目经理沟通、明确项目需求,让团队的技术工作不乱
  2. 系统架构设计、核心算法设计、主要性能攻关
  3. 提高团队成员能力、引进合适人才

# 02. “我”是做技术的,产品、运营做的好不好,不关我事

这个观点虽然我们一看就知道不合价值观,但是在实际的工作里,却是一个挺常见的现象。作为技术leader,保障在技术上把产品、运营的需求,用代码给做出来,变成产品、服务。

一般来说,我们都清楚产品经理对自己的产品目标负责、运营经理对自己的运营方案效果负责;那么作为研发的负责人,我们可以独身于事外、对产品和服务的实际结果,不加关注嘛?

很抱歉的说一句,笔者也曾经有过这样的思维。我负责技术团队,确保技术团队的战斗力,把交给我们实施的需求,都给实现了,就起到了研发这个环节的责任、体现了研发的价值。直到有一次和高德的总裁董振宁先生请教,他对我说:从公司角度看,无论是做技术的、产品的还是做管理的,负责人们都是业务干部,业务做没做好,是考核干部合不合格的标准。

一席话激起千重浪,深刻的击中我自己的认知盲点。对于干部,公司的期望是完成业务目标,拿到业务结果;我们不能在业务结果不好的情况下,说我们产品设计是没问题的、我们开发交付是没问题的,这不叫责权明确,对于干部来讲,这叫甩锅,而且锅只能是给老板来接。

# 03.“他们”技术不行,培养太花时间,等他们做完,我早做完了

我不知道有多少leader们,有没有心里想过、嘴里说过这句话。笔者心里想过,嘴里没有说过。作为因技术能力强、技术产出高而在team里被提拔起来的人,有实力说这句话。客观的实际工作里,也有这样的情况,我们要不要自己动手,取代团队成员应该完成的工作?

我认为是不行的。

首先,精力是不允许的。Leader还有很多其他方向的工作,在写代码这个非常耗时间精力的事情上投入,会严重影响其他工作的展开。一个团队,如果leader不能打理好内外环境,很快就会进入效率降低的阶段。取代他们的职责,是拆东墙补西墙,团队整体的产出依然下降。

其次,对成员的发展不利。遇到困难不能克服,就让leader来做,那成员是很难成长起来的。我们的成长,70%来自于工作。遇到困难时,也是他们成长的最好机会。此时做为leader,应该是花时间帮助他,指导他。这也花时间,但是和直接自己取代来做不一样的,团队成员的能力会因此提高,给将来团队的整体实力、产出提高打下了伏笔。这样既推动了项目的完成进度,也提高了团队的成长。

笔者曾经经历过这个阶段,当时公司成本控制,招聘的同学的技术能力在行业里偏低,水平一般。大部分的工作也是我在做。后来我改变了策略,不管如何,把任务分给他们,约定完成时间。到项目周期的1/3时,我会review下所有人工作的进展情况,分情况进行不同处理:

  • A. 进展符合预期,不管他了,让他继续往前做。
  • B. 进展高于预期50%以内,给予指导,在这个项目上,给他建议,提高效率。
  • C. 进展低于预期50%以内,拿过来我做,追赶上项目工期。

真正落到C选项的,实际很少,大部分在A和B里分流了。对于A种情况,对应的工程师会给予更多的项目和职责,快速成长起来;对于B种情况,对应的工程师能够有效得到帮助,能实实在在的提高自己的工作水平;对于C情况,如果不能带起来,就只能优化了。

最后,如果用这样的思维思考,团队内的氛围会比较差。成员不能承接自己本应该承接的工作,得不到成长锻炼的机会,没有有效的产出,会很容易产生不安全感;人在不安全感的情况下,容易会去互相推脱责任,互相指责、力求自保,诉求最基础的“我没错”的安全需要。

这种氛围下,团队就带散了,有能力的人会离职、转岗,没能力的人会力求不犯错,做为leader的老板,不得不出来解决这个团队的稳定性问题。还好,笔者没有这么干过:)

综上所述,我给研发leader们三个建议:

  1. 在技术工作上,当退则退,保持30%的精力,在某个技术方向上做深,利用业余时间提高技术广度。保持技术深度和广度的同时,留出精力去做管理性的工作。充分挖掘团队资源,去完成团队任务。
  2. 作为技术leader,身在技术,心在业务,始终站在业务成功的角度思考问题。
  3. 为团队培养人才、引进人才,优化不合适的人才;是团队建设永远正确的真理。

# 规划方向篇

规划这个词,对很多leader来说,是个伟大而又玄乎的词,经常的会听到“咱们先做个规划”、“年度规划”、“季度规划”,规划是个啥东西,怎么做对?怎么做好?

不过有一个好消息是,在整体公司组织中,作为技术团队leader角色时,是执行角色;技术团队leader主要是承接部门经理或总监安排的任务,体现执行方面的能力和效率,还不需要做高大上的“规划”。

那读者可能要问,既然如此,这篇文章你写个啥?笔者想说,虽然不需要做规划,但是总得有能力理解上级做的规划,理解执行的任务来自什么。我们从这几个层面来看规划:

  1. 企业级规划
  2. 事业部级规划
  3. 职能部门规划(成本中心)、运营部门业务规划(利润中心)

我们分别来看一下,怎么来理解各层级的规划。

# 企业业务规划

企业的规划一般来自三个方向:

  • 业务规划:业务规模、收入
  • 人力规划:供给“人才”,实现收入的目标
  • 财务规划:资金流、成本、利润

# 01. 业务规划

业务规划是指公司的业务规模收入方面的计划。贝壳在2019年,定下的目标是GMV达到2万亿【百度上能公开检索到,这不是泄漏公司机密哈】,当然还有其他指标,不过核心的是业务的GMV指标。商业企业是一个经济组织,其目标一定是商业目标,大白话就是钱;业务规模、增长率、开拓新市场等,无一不回归到商业利益上来。

在这里解释一下,企业的直接目标是商业利益,但长远目标和存在的意识,不是商业利益。企业的使命和愿景,是存在的意义和看得到的未来,一般不会是商业利益;贝壳的使命是有尊严的服务者和更美好的服务;贝壳的愿景是服务2亿家庭的品质居住平台。因使命和愿景,是一个公司更长久的意义,不是规划出来的,而是创始人的理想、企业社会责任和价值的表达。

企业级的业务规划,比较简单,一下就能看懂。如果企业的目标很长很难记,那对几万人的公司,就是个灾难。

# 02. 人力规划

人力规划,主要关注的是用什么样的人来完成业务收入。 人力规划和财务的规划是有关联的,因为财务需要控制预算,保障资金流健康。在合理的人力成本预算下,HR制定人力政策,和Leader们关联比较大的,是年度HC有多少、调薪幅度有多少、绩效考核方案怎么做。

郑云端先生曾说,HR的三板斧是:招聘、培训和激励;在规划上,基本也是围绕着这三个方面进行展开。通过招聘、培训和激励机制建设,来“供给”实现业务需要的人才。

# 03. 财务规划

在财务规划上,我认为最核心的是保障资金流稳定,其次是成本控制。 资金流是企业的血液,企业业务好好的、员工好好的,看似一切健康无比,血液不流动了,会瞬间倒下。我们知道的OFO、互联网金融的崩盘,主要都是资金流出了问题。

获得资金流的方法,主要是公司自身业务收入(造血能力)、融资、贷款,当然也有创始人的自有资金,笔者有个朋友,曾经卖了北京房子,作为创业资本。大部分的CFO,不是在找钱,就是在找钱的路上。

除了资金流保障、成本管理,近些年管理会计兴起,代表是全面预算,对业务规模收入进行测算、各类费用、成本、资金进行测算,通过预算分配资源,实现目标。

# 事业部级规划

事业部可以理解成一个不太完整的公司,一般情况下独立核算。事业部作为一个业务单元,一般在业务方面完全自主、人事和财务方面有一定的自主权。

# 01. 业务规划

事业部的业务规划,首先是对公司业务规划的拆解;一般拆解后,整体会超过公司的业务规划。事业部的业务规划,除了收入的目标外(比如南部战区目标XX亿GMV),还要有支持业务发展的中长期能力建设目标

对于能力建设目标,举个例子,如贝壳效率工程的SaaS HR团队,承载支持加盟体系关于组织、人的信息化,通过把加盟商、经纪人等的信息化做准、做好了,才能和贝壳平台做更好的连接。这就是对业务的一个中长期能力建设,对未来业务目标的提升,起着长期而又重要的作用

# 02. 人事规划

事业部在认识规划方面,首先是在企业人事规划的范畴类,不能违背企业的人事规划(偶尔出现事业部挑战规则,突破企业人事规划的现象也存在)。人事规划基本是在招聘、培训和激励三个方面。

在招聘上,事业部的人力HC预算,一定在企业规划之内。实际操作上,事业部负责人有很大的动力通过人力扩充,加速业务的增长。美团曾经经历过这样一个阶段,业务快速增长时,公司HR发现控不住事业部的人员规模。因为事业部的负责人也是集团的高管,有比较大的权限,突破HR政策。

在培训上,一般是成熟的组织比较重视,对应的培训预算、培训内容和培训方法也更完善。目前在我的工作经历中,贝壳当之无愧是最重视培训的一家。在贝壳一年多的时间里,我接受的培训是以前的一倍多。

在激励上,一般是制定公司的绩效管理办法,通过绩效考核,为优秀的人才提供更好的变动薪酬和晋升空间。另外,通过对运营的绩效规则的设定,激励运营方向的员工,获得公司期望的业务结果。

事业部的人事规划不细展开,因为事业部也不是我们技术leader工作的界面。

# 03. 财务规划

事业部的财务规划,相对做的比较细,对收入、成本要做比较准确的预测,编制收入预算,测试业务规模、收入; 并且按月进行滚动,按实际发生的业务规模、收入,进行预实对比,调整后继收入预算。

同时对费用预算、成本预算进行编制。费用预算和成本预算要看各个公司实际业务(生产的产品、提供的服务)的情况,发生的费用和成本类型大不一样。

事业部的财务规划,最后反应在三张表上:资产负债表、现金流量表、利润表。

# 技术团队规划

我们依然用“规划”这个高大上的词吧,技术团队主要在做执行工作,但执行工作来源于企业一层层的规划。

BTW,做C端业务和做B端业务,在公司的决策-执行上差异很大;做C端业务,公司一般很重视扁平化,让一线呼叫总部炮火支持,因为C端业务,对于一线员工,理解起来不那么困难,容易共情。而B端业务高度复杂,理解判断困难,一般从上到下的决策比较多。在B端公司,理解逐层的规划、决策的能力很重要。

# 01. 业务规划-任务转化

企业做业务规划,可能会有个大会宣讲;事业部的规划,可能事业部总经理也会内部进行宣贯;对于技术leader来说,这离自己要执行的任务,还是遥远。这种情况下,技术leader不能等待,而是主动出击,在任务还没有分配下来时,主动和自己的上级沟通,了解规划需要拆分成的任务,甚至参与拆分的过程,向前迈一步。

这样的好处,是技术leader避免了被动承接任务。人在被动接受时,总会带着怀疑和不解的。IT行业从来都很紧凑,当任务分发下来时,已经把上线日期都规划好了,没有太多的时间buffer,让技术leader了解前因后果;技术leader不能在内讲清楚上下文,技术团队就会沦陷为一个干活机器,终日忙碌中,知道自己干什么,不知道自己为什么而干,也不知清楚懂干的事有没有价值。这样的团队,怎么会有积极的氛围呢?怎么不回逐渐进入一种焦虑呢?

往前迈一步,参与规划到业务的转化过程,是我对技术leader的一个建议。这些拆解好的任务,就成了研发团队自己的“规划”。

# 02. 人力规划 – 丰富多彩

人力可能是公司出规章制度最多的一个部门,每一个规章制度,都影响着团队的运作。如考勤、招聘、调薪、晋升、绩效、等等。这在《团队工作方向》里进行展开,下面简单提下招聘和考勤两个重要的场景,本篇不再细述。

技术leader对于招聘工作务必上心,给自己的团队招聘优秀的人才,是leader一个很重要的职责(不是HR的职责),而且在人才选拔上,除了保持团队的梯队合理外,要敢于请进来专业能力比自己强的人。作为技术leader,走向管理岗位,就需要接受团队里专业比自己强的人存在,给他们发挥的空间。

在考勤上,由于从事技术工作的人不少是夜猫子,喜欢晚上安静的时候干活,平时加班也很多,我推崇“自由”的考勤制度。做技术工作,如果自驱能力不够好,很快产出就掉下去了。技术leader发现后,通过绩效管理、辅导的方式,能够有效应对。考勤“自由”,是对工程师的一种信任,当然如果违背信任,对应的惩罚代价也很大。

技术leader一定和自己接口的HR或HRBP,保持高频沟通,来保持团队在人事规章制度上,即使自己不知道,也有人来监督、提醒。

# 03. 财务规划

对于技术团队来说,财务规划一般就是要做好预算费用的编制和控制。 在技术团队,涉及的预算,一般包括:

  1. 行政办公设备预算
  2. 工具软件license预算
  3. 团建预算
  4. 差旅预算
  5. 测试机、短信通道、云服务等预算
  6. 其他

笔者初作预算时,头脑嗡嗡响,一是想不到有那么多预算项目,二是不知道怎么去做,设定多少预算额度合适。这主要是因为隔行如隔山,请教一下做过预算的前辈、自己耐心做几次就熟悉了。

综上,本文概要介绍了业务规划、人事规划、财务规划,帮助技术leader去理解公司的规划,进一步自己参与规划拆解为研发任务的过程,提供一定的知识基础。

# 协调方向篇

协调方向的工作非常广,涉及到方方面面,我们在公司的协作中,到底为什么这么难?不探究本质,是难以找到解决方案的。笔者认为,协调遇到的困难,本质的原因,是组织内天然存在的部门墙。本文从部门墙维度,来看部门的协作、项目协作的改进。此篇和技术团队Leader有关,但是其实延伸的更远,更多职业阶段,都受到协调工作的“苦难”;同时也探讨下,如何在工作里,利用部门墙,使之产生不一样、难以抗拒的价值。

# 01. 什么是部门(团队)墙?

给部门墙下一个定义,因多种因素产生的部门间不能有效协作的隐形障碍,并对公司整体目标达成产生伤害。部门墙可以归纳出以下几个主要诱因:

  • 目标不同产生的部门墙
  • 信息不透明产生的部门墙
  • 观点不一致产生的部门墙
  • 节奏(优先级)不一致而产生的部门墙
  • 专业理解不一致而产生的部门墙
  • 因主导权竞争而产生的部门墙

在复杂的中大型企业里,为了完成业务,制造产品或提供服务,需要不同能力、技能和专业的人,进行系统性的配合,才能完成。这些人才因业务不同而分开、因职责不同而分开、因地域不同而分开、或因管理规模切分而分开;形成不同的部门和团队组织。

每个团队自组建那一天起,他就是一个生命体,有自己的意志、灵魂,有自己的欲望、思想;有自己的新陈代谢,有自己的生老病死。每个team成员,都是其中的一个器官或细胞,只不过和我们所熟知的生命器官形态、功能并不一样。

在从事工作的18年后,我回忆了所有我工作过的团队、部门,很不幸的是,没有一个团队或部门,是没有部门墙的;在存续的生命周期里,都对外产生了协作的或大或小的问题。部门墙和企业文化无关、和员工素质无关,是企业多部门、多团队组织的自然存在

# 02. 部门墙的典型事例

先看看因目标不同而产生的部门墙。举一个身边的例子,2019年技术部门启动了UC的重构项目,因这个系统发生过多起公司A级故障,非常影响公司业务的稳定开展;产品部门启动了HR体系数据治理,要把人事数据的准确率提高到99%;这两个目标对于公司,都是很有价值、有必要去完成的项目。

但是这两个目标产生了对产品资源和研发资源的竞争;UC的重构优化是需要产品经理的;人事数据治理也是需要技术的;双方对对方的资源投入都不满意,以至于投诉到了我这里。产生部门墙的后果也很严重,产品团队要把负责UC优化的PM给撤出来,减少对UC项目的支持;结果让两个团队之间剑拔弩张。

后来通过沟通,保障了一个全职的PM,来推进UC的重构、优化,同时研发团队优化资源调配,加大对数据治理项目的支持;最终两个项目,都完成了自己的目标。

下面看一个信息不透明产生的部门墙例子;我刚进一个公司,负责一块新业务时,研发团队刚刚组建(5个人),而此时产品已经有6个人了。这在我看来是有问题的,意味着产品要么做的设计没有资源实现,要么产品在非常低效的产出。我刚来负责这个部门,当向PM团队提出这个问题时,PM团队不愿意关于这个问题进行深入的沟通,只是反馈我们都很忙,工作量都很满。

这样的信息不透明,产生的结果是很负面的,后续的解决过程,几乎一直在对抗的负面状态;后来我思考这个问题,可能是因为我的比较重的技术背景,让PM团队不愿意接受我来lead,于是调整姿态,以逐个具体产品方案的review,来降低信息不透明的问题,通过3个月的持久努力,解决了产品和技术团队的配比问题。

这里再举一个节奏不一致导致的部门墙问题,去年我们启动了一个业财对接的项目;财务对这个业务的核算非常重视,因为业务规模比较大;而此时,业务部门的重心放在业务的规范和线上化上,也认同业务的核算是必须要做的,但是得先让业务系统跑顺起来。在持续了9个月的时间里,业财对接一直低效的推进,财务的数据规则、流程规范,在业务系统里得不到落地。这是典型的两个部门节奏不一致导致的部门墙,过程中也是非常痛苦,业务负责业财对接的团队,士气低迷;而财务同事,也非常泄气。

直到今年,业务系统把财务核算纳入到整体系统规范、标准化中来,提高了优先级,和财务部门的目标优先级相匹配,这个项目才有了起色。

这样的例子太多了,我想各位读者静思一下,能列出的实际例子,比我列举的更多、更丰富,有很多的因素,能够撞上“部门墙”,降低部门效率,扰乱团队的合作氛围。

# 03. 如何跨越部门墙

没有一个组织,不希望团队、部门间能够无间的协作;站在公司层面,都是公司的资源,有效的把资源转成公司的产出,才是公司这个组织所期许的。对于无处不在的部门墙,我们如何能够有效的跨越呢?笔者据自己的经验,列出以下几个方法:

  • 个体主动放弃防御心理
  • 在对外寻求合作时,务必提前把事情想清楚
  • 在支持外部发起的合作时,务必努力去把信息接受全
  • 站高一层,跳出当前部门,从更高的层面看协作

# 个体主动放弃防御心理

这对于职场里的每个人,都非常有价值。防御心理使得我们只想听那些我们想听的话,而错失其他信息的输入、曲解外界的信息输入。在对外的沟通中,不预设对方的态度、目的,以避免形成成见,以空杯心态迎接外界。这能够最大限度的让我们接受外面真实的信息,减少误判。

笔者在这方面,也踩过很多坑;无来由的怀疑对方的动机和目的,以至于在具体工作配合上,采取不信任、消极的态度。时而反思自己,方能减少这样的错误。

# 对外寻求合作时,把事情想清楚

合作从来都是难的事情,尤其在信任不足的场景下(如果有信任,那合作是很快能达成的,不需要检查那么多合作的预置条件),对此我们有必要把合作的目标、计划、资源、价值想的清楚了,去对外沟通。每个团队、部门都是繁忙的(大部分情况下),自己准备充分,是对别人的尊重,是获得支持的有效方法。

我们的技术部门和公司的基础架构平台有非常好的合作,去年我们把团队所有的公共技术组件资源,都转交到了基础架构平台,以响应公司的基础技术环境统一建设的号召。但是我们团队的技术人员,非常希望通过基础技术组件的建设,来提高自己的技术能力和视角。因此我们创新性的提出“合作共建”的方法,主动提出参与基础架构平台的系统建设,即为基础架构平台提供资源的支持,也为我们部门的技术发展、技术组件引进,提供了可能,对技术团队的稳定、成长,有很好的帮助。

# 在支持外部发起的合作时,务必努力去把信息接受全

在外界需要我们配合协作时,作为负责人,我们将最终要判断要不要合作、投入多大力度合作。这是一个决策机制,依赖信息准确、丰富。不仅仅对方把信息push过来,同时我们自己也要主动的去沟通获取重要信息,判断是否有价值做、是否有资源做。当然,既要根据信息做出正向支持的决策,也要做出负向支持的决策(不见得所有的协作都是有必要的)。

近期我们启动了一个项目,看似非常紧急,调动我们团队的工程师加班加点,一阵猛如虎的操作以后,发现这事情好像也没有这么重要;再回过头来Review时,确认是可以长线做的,不是异常紧急的项目。这是典型的一个信息没有完全接受,做出的一个决策结果。

建议可以结构化的对外接受信息,从以下几个方面主动获取信息:

  • 清晰的目标价值(最好是数字表达的目标)
  • 明确的进度计划
  • 需要的资源投入
  • 完成后如何评价项目价值 (最好也是可衡量的数字化价值)

# 站高一层,跳出当前部门,从更高的层面看协作

最重要的事,一般放在最后讲。我认为这是跳出部门墙进行合作的最有效办法。在二维空间,部门墙是拦路虎,迂回到很远才能越过去;但是如果升维到三位空间,部门墙就是可以跳跃过去的。

从更高层面看协作

站在跨越了部门的更高维度思考,可以让我们避开二维的“部门墙”思维陷阱,在更高的维度看,A和B同时在一个新的“组织”里,是内部的关系。

Leader如果具备更高维度的思考能力,或做这样的尝试(这是个难的事),对自己个人的提高、发展是大有裨益的。在外界看来,这个leader的格局很高,做事公正无私,跨部门合作也容易产生更有价值的成绩,实在是发展、晋升的必备良药。

# 04. 如何利用部门墙

既然部门墙如此客观的存在,那就没有利的一面嘛?凡事都有两面性,我们应当合理的利用部门墙。

首先,部门墙容易产生“领地”意识; 对于领地意识,是个有好有坏的典型。一方面,“领地”意识导致别人难以进入,提供更好的方案;另一方面,“领地”意识产生极强的责任心,很宝贵的责任心。 我承认我也是有“领地”意识的,效率工程是我们的“领地”,这里出现问题,责无旁贷,不需要公司push,我们就回去解决;而同时,也确实限制了其他部门对效率工程方面的贡献。

其次,部门墙使得决策延长、不靠谱的决策被挡住。 一个部门内的事情,可以很快、高效的决定,但是也不会有人来review;跨部门的协作,天然的就加了这样一道机制,让另一双眼睛来审视,决策是否正确、是否可以更好。

最后,部门墙让部门的不同意见、看法产生碰撞,如果能够因势利导,这样的碰撞也许能够碰触比原来不一样的思考、决策,甚至是创新。 部门之间的碰撞越大,说明分歧越大,分歧越大,为了弥补分歧,就要提出更好的方案,来覆盖多方的分歧。这岂不是创新的温床?

综上所述,部门墙的弊端,在技术Leader这一职业阶段,会比部门墙的利端更大;但是随着职业的发展,有效利用部门墙,会带来意想不到的价值。

# 团队方向篇

敬请期待...