不会带团队的领导,只能自己干到死
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
。
康威定律,从琐事中抽出身来
曾经有一段时间,我努力确保每一件小事都不出问题,然而我却发现,在这个过程中我我忽视了很多其它我更应该思考和重视的问题。我当时甚至不知道这些问题的存在,过了很长时间以后才知道。那段时间,尽管我们已经有几十号员工了,但我还是忙得脚不离地,尽最大努力自己多做事。我会参加绝大部分的公司会议,员工遇到不管遇到什么问题都来问我,而我必须要为他们提供解决问题的方案。这种忙其实并非好事。
这里存在一个真正的危险:作为领导者,你可能会为自己的异常忙碌而自我感觉良好,感觉就像自己为公司创造了多少价值一样。其实背后隐藏的是正在快速堆积的层层危机。
那段时间,我没有时间停下来去思考。然而当其中一位工程师向我说起康威定律时,我顿时愣住了,立刻决定花时间对此进行反省。康威定律的大概意思是这样的:“公司开发的产品和服务其实都是公司自身组织架构、沟通与工作方式的反映。” 确实如此,很多时候,我们从产品和服务的架构就能看出公司的组织架构。
在 Yammer 发展初期,我只负责监督一个小的工程师团队开发最初的产品,他们都在代码库里开发,然而随着越来越多工程师的加入,那个代码库变得日益庞大,也愈加难以管理,就像日益庞大的
工程师团队本身面临的问题一样。只有当他们将所有工程师分为不同的小组后,他们也得以将庞大的代码库巧妙地分解成不同的小服务。我发现,人员的组织架构是可以改变产品的架构的。
在上个世纪 90年代,我还是一位 web 开发者,那时还没有任何流程的概念,人们也不重视这一块。工程师只是简单地在网络服务器上编辑活动文件。那时也没有所谓的测试,更没有版本控制。如果放在今天,那样绝对乱套了。现在我们要想让众多工程师在一块高效工作,我们就需要有一个开发方法学。除了适用于工程师的开发方法学外,现在很多公司甚至缺少一个有效的组织方法学:一个不是什么工作都要你亲自来管的情况下依然能确保公司高效运转的系统或流程。
在 Yammer 的时候,我们做的非常正确的一件事是:持续迭代和完善开发方法。随着团队规模的扩大,团队的开发效率反而降低了,这迫使大家不得不思考这样一个问题:“一个团队在黑客马拉松上开发产品的速度为何比平日里开发快那么多?” 大家开始意识到,因为我们平时同时在开发的东西太多,而在开发过程中的沟通效率却又非常低效。大多数时间里,人们需要同时兼顾多个项目。
后来我们制定了一个规则:在一个新项目所需的全部人员没有齐备并可以完全投入到这个项目里之前,我们是不会启动这个项目的。一旦人员齐备,我们会赋予这个新组建的项目团队绝对的自主权和决策权,不需要外部授权审批就能独自把项目做好。一般情况下,一个项目 2-10 周能完成。一个项目完成后,团队就会解散,大家再各自进入其它项目。通过这种方法,公司创始人就不需要凡事亲力亲为。例如,践行上面的规定后,我就不需要亲自过问开发架构或编码规范,他们自己完全可以高效完成。
作为领导者,你的目标是建立一个不再依靠你、甚至不需要你的组织架构和工作流程。节奏的力量:如何让公司发展富有节奏
如何才能建立这样一个体系:在不需要你监督的情况下,公司各项重大的事务依然能有条不紊的进行。对于这个问题,Pisoni 给出的首要建议是:战斗节奏。
在公司的日常运营中,领导者要做很多工作,也要做很多决策。然而在大部分情况下,所做的工作都是没有任何目的计划性的。对于何时做决策、何时转变战略、何时重新评估,这些都没有任何节奏,也没有充足的理由。所有这些工作如果都能有条不紊、有节奏地进行,你将会节省很多时间,工作效率也会提高很多。节奏有利于加速执行,可以省去很多不必要的会议和监督检查。有几个地方,如果能够做好的话,是有助于快速推动公司发展的,但这些地方也恰恰是很多公司容易出问题的地方。
1. 角色和职责
大部分创业公司看惯了大公司的组织架构和行事作风,就轻而易举地得出这个结论:正是大公司严
格的组织架构和各种头衔阻碍了公司的发展步伐。这有一定道理,那一套东西确实在一定程度上阻碍了公司的发展。如果仅凭此就认为清除发展障碍的最佳解决方案就是去除组织架构、也撤了头衔的话,这就错了。这样做反而会更严重地阻碍公司的发展。如果没有清晰的职责定位,公司就会很容易陷入决策瘫痪和争执不休地状态。我自己从来没见过哪个公司在发展到一定程度后依然觉得自己不需要任何组织架构的。
然而,就算没有严格的组织架构和头衔也是可以确保岗位职责定位清晰的,方法就是定位不再依附于头衔或组织架构的清晰的角色与职责。这些角色应该是临时且灵活性的。要想知道公司究竟需要哪些角色,可以通过回想公司过去和想象未来必须要做哪些决策来确定。看公司里哪些问题最常出现,尤其是那些因为找不到责任人而总是需要你和公司其他领导亲自去决策的问题。下面是有关职责定位的两个核心要点:
创建一个定义角色和职责的公开文档,确保公司所有人都能看到。每个角色清单需要包含的信息:角色的重要考核指标,谁担任这个角色,这个角色的职责是什么,这个角色的任期是多久。
作为团队领导者,一定不要随意干预被赋予相应角色的员工,给予他们绝对的控制权。如果做不到这一点,好事也会变成坏事。
做到这些后,同时还要明确所有角色都不是永久的。它只是一个角色,不是一个头衔,也不是固定职位。在 Yammer 的时候,我是公司的 CTO,当时公司还有一个技术副总裁和几位技术主管。当时技术新人的岗位培训和管理这个工作在现有的组织架构和头衔内是没人直接负责的,属于管理漏洞。每当出现这类问题,最后都会推给我。当时我还为自己能快速决策、推动工作而自我感觉良好,但我没意识到,正是这些东西阻碍了我们快速发展的步伐。之所以会出现有的工作没人负责的问题,正是由于角色和职责不清才导致的。
现在回想起来,我真希望自己当时就能做到让公司的每项重要工作都有明确的负责人来负责,同时还能每个月重新评估一次。
Pisoni 建议每个月进行一次角色和职责的评估检查,内容如下:
充当相应角色的所有人都要快速回顾他们在这一角色上所开展的工作。
让大家针对是否需要增加或撤除某些角色提出意见建议,或是对现有角色的职责进行调整或加入新的职责。在某些情况下,有些任务可能以后就不会再出现了,这种情况下就不再需要负责这个任务的角色存在了,需要让他们担任其他角色。
大家提的建议是否采纳,需要通过综合决策(Intergrative Decision Making)流程来决定。让一群人共同决定是否采纳大家的建议,而不是老大说了算。在综合决策流程下,每个人都可以提建议。提了建议之后,会有一轮针对所提建议的问答环节,问答之后,提议者可以对自己的提议进行调整,接着会有最后一轮的答疑环节。这么做是为了避免出现不管什么建议都采纳的情况。