领导梯队在ThoughtWorks中国

我们常宣称ThoughtWorks是一个扁平组织,并为此而自豪。不过最近有一位离职的ThoughtWorker写了一篇颇有影响的blog,文中表达了对ThoughtWorks的喜爱,却又不乏苦涩地诉说了这个扁平组织缺乏制度和执行力带来的“混沌”(Chaos)状态。ThoughtWorks从文化诉求到组织设计都希望尽量减少层级,然而扁平并不意味着应该缺乏领导力。

我按照领导梯队模型(The Leadership Pipeline: How to Build the Leadership Powered Company),梳理了一下我们的几类角色。有人可能会说领导梯队和管理层级看上去是如此相似,前者是不是只是用来美化后者的华丽包装?我的理解,这两者从责任上讲确有相似之处,但是在行为模式上,管理层级强调的是汇报线(Command Chain),领导梯队强调的是工作理念,而最后是人们的行为模式定义了一个组织的文化。

ThoughtWorks是一个有自己使命的组织,在履行使命的路途上更是需要有各种不同类型的优秀领导人物不断涌现出来。随着规模的增长、业务的多样化,我们看到更多这样的机会正在涌现。这些机会要求不少ThoughtWorker承担不同的领导角色,期望他们具备与之前不同的能力和行为模式。

个人贡献者

ThoughtWorks跟所有组织一样,大多数人必然都是个人贡献者。在ThoughtWorks这样的专业服务公司,一个人的贡献和对公司的重要性并不一定通过承担管理性质的角色来体现。如果看看ThoughtWorks话语体系里提到的各种牛人,他们有特定领域的技术专家或是阅历丰富的架构师,也有曾经的公司高管,今天的管理教练和组织转型顾问,其实大多都是个人贡献者。这也是为什么一直以来我们的职级体系并不会跟岗位挂钩。

大部分ThoughtWorker都希望能专注在专业服务领域做出一番成绩,但也有同事由于这样或是那样的原因,主动或是被动的进入到了一个“领导梯队”当中。

一线Lead (领导或经理)

一线lead通常是刚刚从个人贡献者的角色转变而来,其中很多都是第一次带团队。在我们的场景下,交付中心的Team lead,项目经理,运营部门functional团队的lead都是典型的一线lead。

ThoughtWorks的一线lead大多在作为个人贡献者的时候,既展现了出色的专业技能,同时又发挥了辅导小伙伴和与外部stakeholder沟通协调的能力,因而被选为团队的领导者。相对个人贡献者,这时仅仅依赖超强的专业技能或是个人解决问题的能力已不足够。一线lead要帮助团队定目标,做计划,保执行,还要通过持续的反馈和其它团队建设手段来提升团队的效能和氛围。

另一个容易被察觉的不同是时间管理。他们相当的时间会用于各种不同的沟通活动,比如一对一辅导团队成员、团队计划、回顾会议,还有跟客户、销售、分公司总经理等外部相关方的沟通,一不小心就发现自己陷入到了讨厌的文山会海当中。然而如果回避这些沟通活动,却又很难履行Lead的责任。与此同时,工作理念上的一个转变是需要把工作的重心从自己胜任专业任务更多地转到帮助小伙伴的成功上。

很多同事在这样的角色上尝试锻炼了一段时间后,会根据自己的热情所在,决定是以领导管理角色作为职业发展方向,还是转向业务专家。一线Lead是ThoughtWorks领导梯队的后备军。

部门Head

ThoughtWorks的部门Head一般包含分公司总经理(Office Principal),成熟BU的Head,功能部门Head。他们要负责本部门的发展策略、资源配置、人员的招聘和培养,以及跟其它业务线和部门的协调,更要确保本部门的发展符合公司战略和运营的规划和期望。

我们的一线经理通常不会脱离一线具体业务工作,PS的同事仍然战斗在具体项目上,运营的同事大多数时间也还在处理着相关业务的日常事务。但是对于部门Head来说,他们一般是全职的运营管理人员,只是在特殊时刻或是在一些关键业务上,才会直接承担业务工作,就好像有时候我们看到OP也会过渡性地承担战略客户的交付经理。

判断一个部门Head是否成功的依据,通常要么是直接对标其它Region的相同部门或是业内优秀公司,实现卓越水准。要么就要寻求创新模式,制造跳跃式的差异化优势。我个人的观察是我们的部门Head似乎更倾向于后者的方式。People团队运用微信提供员工支持,协同拉勾网发动创意招聘攻势。本地交付团队积极拓展新型业务开拓新的细分高端市场。UX团队发展出了设计中心服务包。海外交付中心则发挥我们学习型组织的优势,用各种创新和能力提升活动,积极为客户提供更具价值的服务。

部门Head常会面临一个矛盾是局部优化和全局优化。实现部门的直接目标容易遮蔽部门Head另一个不是那么明显的责任,就是作为部门当中拥有公司上下文最多的人,打破部门边界,促进信息和想法在部门间的流动,跟其他部门head以及MD一起做出全局最优的判断和决定,哪怕这样的决定会增加本部门的工作难度,甚至对自己的工作目标有所伤害。不少同事肯定都有这样的记忆,客户要求紧急启动项目,各个办公室、客户团队和业务线不管项目是否跟自己直接相关,都愿意承受巨大压力,左右腾挪,把需要的人员送到现场。

事业部MD

现在ThoughtWorks的事业部基本是按照地区来划分的,大多数事业部的MD都是各个国家和地区 MD。事业部MD的长期目标是树立本事业部的业务愿景,通过愿景的实现来履行公司的使命。我们去年梳理了2022年中国区的愿景,并期望从全新的业务模式带动高速增长、更具影响力的品牌、资源丰富的周边生态系统三个维度达成这个愿景,最后我们以路演的方式在各个office和大家面对面交流这些内容。

MD日常的关注点则是推动变革来达成愿景里设计的To-Be状态。胡凯和我已经开始通过一系列的活动来逐步落实2022愿景里的那些内容,这些活动会覆盖组织结构和协作机制的设计,不过更重要的是发现和发展各种带头人,启动和推进相应的各项投资。

要做到上面的几点,MD还有一个最基本的工作就是要确保本region的业务安全。业务安全的一个条件是盈利目标和增长目标的达成。由于公司全球投资战略和运营规划依据的是各个Region的盈利计划,如果任何一个成熟Region的MD如果没能达成业务目标,都有可导致整个公司花钱的速度快过赚钱的速度,从而给可持续运营带来风险。

最后,不管是个人职业发展需要,希望通过借助更大的团队和平台做些一个人干不了的事情,还是为了达成公司的期望和要求,我希望更多的ThoughtWorker勇敢地站出来,抓住机会,承担起更大的责任。

MD心声

过去几次,我发现总会从大家的讨论中得到很多启发,所以这次还是抛出三个我还在思考的问题,希望听到大家的看法:

  1. 承担领导角色的一个重要特质是有担当,如何鼓励在公司里形成有担当的氛围?
  2. 卓越的专业能力和贡献跟领导角色是否冲突?
  3. 鼓励大家当领导是否会形成官本位的倾向?

更多精彩洞见,请关注微信公众号:思特沃克

Share

创新在ThoughtWorks

当我们说鼓励和孵化创新的时候,其实是说如何用创新持续性地产生社会和商业价值。ThoughtWorker从来都不缺乏新鲜的想法,却少有把想法实现的成功案例,而在那些被实现的案例里面,产生影响力和创造出实际价值的就更加稀少。我一直希望通过反思过去,找到通往未来的道路。

我们不局限于技术和产品的创新,还有运营和业务的创新,通过对以往比较出彩的案例做个梳理,大致看到三个来源。

1. ThoughtWorker的个人兴趣和热情

很多ThoughtWorker工作之外总想搞点自己的东西。有些同学在感兴趣的新兴技术领域做出探索性的尝试,于是金明在云上做DevOps产品,西安有项目团队做了看房机器人朵拉;有些同学要解决一个手头的问题,于是王秋、刘冉做了视觉感知测试系统-Viff,郑晔做了Moco,另外的移动测试工具和快速开发平台也是这么产生;同样的,有些同学希望对一些自己关心的社会问题尽一己之力,于是朱晨为听力障碍的人群做了心声;仝健在石家庄尝试把我们开发实践和技术纳入到学校的教育体系;这些创新是由兴趣和好奇心所激发,由热情所驱动。

2. 解决业务挑战

ThoughtWorks是一家专业服务公司,服务公司的业务就是人的业务。如何招人、培养人并留住合适的人是我们每天都在思考和头疼的问题。这样的领域自然就会出现各种想法和创新,其中小巨人和招财猫就是两个典型的例子。小巨人的思路来自中国区CTO徐昊想要解决的两个问题,一个是如何让年轻人快速成长为能够独当一面的技术领导人,另一个则是寻求突破ThoughtWorks软件交付的模式。招财猫则是来源于Recruiting团队一年一度校招痛苦,如何让应聘者方便提交申请,及时跟踪申请进程,如何让Recruiter高效无误地处理数以千计的申请和简历。行易的来源也是类似,米高看到了admin和财务团队在往返处理差旅申请上花费的时间和精力,以及邮件沟通带来的延迟和失误等问题,于是开始着手解决。

3. 捕捉市场机会

ThoughtWorks合作的客户不少是行业领先的公司,做的项目大多都是关于一些前瞻性的商业思路。这给了我们一个别人不常有的优势,那就是可以借助客户的眼睛发现面临变革的行业和领域,把握市场窗口。我们在互联网金融领域做的P2P,在零售做的O2O其实都是如此。这些思路本身都不出奇,业界都已经叫得火热了,但通过项目实操和观察客户的运作,我们获得了一手经验,这对我们思考自己的独特定位并形成一个可行的方案,就显得至关重要。

这三个来源之间其实有着千丝万缕的联系,每个创新大多涉及其中至少两个因素。

如果我们把这些创新分类,大概可以分为如下几类:人员能力、运营效率、新的产品服务、还有技术工具和社会影响相关的内容。这几个类别清晰地指示出了ThoughtWorks和ThoughtWorker的关注点。

有的时候光凭发起者的一己之力或是召集几个小伙伴就可以将创新的想法实现,但在不少情况下是需要公司的支持,才有可能从一个小树苗成长为参天大树。

在公司,现在至少有两条路径可以获得投资,成为官方孵化的种子。 路径一:推销(Pitch)— 孵化(Incubation)— 成长或成为业务常态(Grow/BAU)

推销(Pitch):在ThoughtWorks,仅仅推销想法通常不会有什么好结果。Idea is cheap,迎面而来的大都只会是板儿砖。个人的热情和持续投入才是赢得他人认可的良方,而热情和投入是无法靠嘴巴说来验证的,人们想看到行动和证据。这样的证据通常体现为大量个人时间和精力的投入。我们看看前人们在获得支持之前都干了些什么。米高跟何飞一起用业余时间完成了行易的大多数功能,朱晨和小伙伴们也是用业余时间做出了心声的原型,金明在公司决定投资之前,花了1年的时间摸索和推动云计算技术的使用,并有一家客户在生产环境试用。也就是说,获得支持有三个tips:个人时间和精力的长期投入,产品和服务原型,用户认可的证据。

作为公司投资的决策人之一,我在做决定的时候会考虑几个因素,很难说得上客观、科学,更多只是经验的积累。

首先,风投行业有句老话,“投的是团队不是项目”,这句话确实有几分真实。太阳底下没有新鲜事。是否能把事情干成了,还是看人。

第二个因素是市场机会。这个对应到雷军那个著名的比喻“风口上猪都能飞起来”。

第三个因素看跟ThoughtWorks的基因和战略之间的吻合度。不是说创新,不是说革自己的命吗?为什么还要强调协同效应呢?寻求突破并不是去陌生的战场用陌生的能力跟陌生的竞争对手战斗,我们毕竟不是专业搞风险投资的,要充分利用自己在文化、组织和资源上的优势来进入新的领域。

第四个因素是市场规模。公司在判断是否要投入一个产品或服务的创新时,一个重要的事情是分析这个创新所试图解决的问题,判断这个问题的市场价值有多大,说白了就是潜在收益。

孵化(Incubation):一旦获得公司的投资,进入孵化阶段,目标就是建设核心团队,形成面向市场的产品或服务,并让客户买单。这里的客户可以是内部客户,也可以是外部客户,买单可以理解为有收入,也可以理解为产生了真正的价值。

成长或成为业务常态(Grow/BAU):最后,如果没有失败或是由于各种内外部原因被干掉,创新需要在可预期是时间内进入成熟增长阶段或成为业务常态。

除了通过直接MD推销获取支持,还有一条路径:创新大赛。每年一次的中国区创新大赛,你可以向内部专家评委和大众评委推销创意并赢取投资机会。如果你担心自己的创意熬不过MD的综合权衡,不妨试试这条路。


更多精彩洞见,请关注微信公众号:思特沃克

Share

ThoughtWorks的下一个春天在哪里?

过去,很多人是因为敏捷、因为Martin Fowler知道ThoughtWorks的。今天,敏捷已经渐渐融入软件开发的主流话语体系。这让我不得不努力思考,我们凭借什么样的优势能在下一个5年里持续地领先于竞争对手呢?

当考虑竞争优势的时候,各家顾问和大师们总能祭出林林总总的分析框架,大体可分为“自外而内”和“自内而外”两类。作为一个过气咨询师,我也不可免俗地选了一个框架。我没用常见的“自外而内”,如著名的波特五力法,而是挑了一种较少人知的“自内而外”法 – 基于资源的竞争优势(Resource-Based Theory of Competitive Advantage)。

ThoughtWorks有一句口号叫 “Technology at the Core”。这里Technology的解读可以延伸到设计、分析、数据等各项专业领域。ThoughtWorks的资源,其实就是ThoughtWorker的技能和积累在组织中的know-how。这些资源让我们在完成各种客户任务时,展现出超越竞争对手的能力。

分析我们近10年的历史,ThoughtWorks展现出的是两种优势。一个是发挥领先经验的经济价值,ThoughtWorks能比其它公司更快地学习和采纳新的方法和技术,敏捷和RoR的掌握和运用就是这样的例子;另一个是让高复杂度的能力成为阻击竞争对手的壁垒。能力的形成,源于个体之间复杂的交互和学习网络,这个网络则依赖于组织结构、氛围和业务模式等要素。比如跨界而关联的能力就是一种复杂度,正如我们所说,“ThoughtWorks是软件开发公司里设计最好的,能做设计的公司里软件开发最好的”,这种复杂度使得模仿变得非常困难。

明天,我们的资源和能力能在什么领域产生重大的价值并取得优势的呢?

著名的创新机构DARPA(Defence Advanced Research Projects Agency)有两个选择创新的标准,其中一个是识别已经发展到拐点的科学领域,用新的方法解决一个实际的问题。这个标准对我们也有借鉴意义,只是我们的目标不是科学领域,而是技术领域和商业领域。

以商业领域为例,哪些方面正面临着拐点,商业的运作正在被哪些技术,特别是我们比较擅长的技术所颠覆呢?回过头来看看我们已经选择的两个领域:金融(参见Mckinsey report:The rise of the digital bank )和零售(参见Mckinsey report: How digital is transforming retail )。最新的互联网、移动技术和模式对这两个行业产生了天翻地覆的冲击,各大主要玩家都在积极求变,而这正是ThoughtWorks的机会所在。

然而,虽然我们在上述这些领域或许有点这样那样的优势,却远远不足以让我们占据领先的位置和建立竞争壁垒。除了业务领域知识的欠缺外,我们在技术上的差距又在哪里?如何才能跨越这些差距?

安全:在互联网金融领域,安全会是我们的一个短板。“自2014年3月16日起,网贷之家官网持续多日受到黑客的严重恶意攻击,持续十分钟的30G流量攻击,同时数万IP的CC攻击,短短几小时内6亿次的连续攻击。”( http://www.csdn.net/article/a/2014-04-02/302486)大家也知道,从ThoughtWorks内部孵化产品 – 金数据也曾遭遇类似的攻击,并且因此中断服务近12个小时。这还不是最糟的,如果安全做得不好,还可能泄露用户隐私信息,甚至给客户造成财务上的巨大损失。我们虽然正在学习和提升安全方面的能力,并且也在招聘相关方向的专家,但能力的积累不是一天两天能做到的。我们如何能够尽快补齐这个短板?

移动与硬件:在零售领域,我们的突破方向是数字和实体世界的体验融合,而移动和硬件将是体验的关键。这是一个创新层出不穷的领域,却又是缺乏前人成功经验的领域(DARPA另一个选择创新的标准:识别一个现有技术所还不能解决的发展中问题),我们的路在何方?IoT(Internet of Things)还是增强现实(Augmented reality)的商业应用场景?

数据驱动:我们不能仅关注交易和体验的界面,如果要让运营者获取超越对手的价值,则不得不提到数据。数据驱动的体验设计,数据驱动的市场定位,数据驱动的营销,数据驱动的风险控制,要做到这些,需要我们不仅能够帮助客户搭建大数据基础设施,还要能够娴熟运用不同商业场景下所需的分析方法和工具。对我们来说这又是一个跨界的能力,如何取得?

MD心声

我们有很多其它的差距,我还不清楚;还有很多其它的问题,我还没有答案;除了金融和零售,是否其它的领域也面临类似的拐点,我也不知道。不过,我却并不是特别着急,ThoughtWorks聪明者众,我们并不缺乏有热情,愿意投入的人,他们会是提供上述问题最佳答案的人。

作为我个人而言,最重要的就是发现这些愿意提出问题、探索答案,并愿意付出努力的“内部创业者”,为他们创造合适的平台和足够的空间,积极实现他们个人和ThoughtWorks的成功。如果你也是这其中一员,请不要犹豫,向前一步!


作者注:ThoughtWorks在2016年选择了IoT和数据驱动的智能服务作为重点投入的技术战略方向,探索创新的客户商业场景。

编者按:MD为寻求TW未来的探索和焦虑跃然纸上。


更多精彩洞见,请关注微信公众号:思特沃克

Share

把“墙”推倒 - 扁平组织中的自主和责任

《MD脑洞》系列之

此篇文章为《MD脑洞》系列第四篇。


最近一段时间内,我常常听到这样的对话……

销售:“研发总是不跟我们销售知会一下就擅自把东西发给客户,人家客户问起来,我们都不知道发生了什么,这弄得我们很被动。”

研发:“我们是专业人员,客户要的就是我们的能力,我们知道怎么弄,为什么一定要通过销售?”

销售:“销售在看一个客户的时候,跟谁说话,什么时候说,说话要到达什么目的,这都是有设计的,不是想到哪儿做到哪儿。研发人员擅自行动或是隐藏信息,更糟的是阳奉阴违,就会破坏了我们的设计。兄弟们总是在擦屁股。”

研发:“但如果客户关系是个黑盒,只是销售代表客户点菜,研发人员按单上菜,这怎么能行?我们又不是卖PC的。销售有销售的设计,我们也有我们的想法。”

由于经常处理这样的矛盾,我荣获了“专业捣糨糊”的称号。回想起来,类似的对话也曾发生在项目经理和团队之间、业务分析和开发之间、现场团队和离岸团队之间,差别只是没那么的剑拔弩张。这种种争执,暴露了一个让我们一直痛苦挣扎、却又有意无意回避的组织问题,就是在ThoughtWorks这样的扁平组织里,如果不希望一切边界和流程都由规章制度或是所谓的领导来决定来拍板,平等的个体之间该如何处理自主能动与行为责任之间的关系?

在讨论这个问题之前,我们首先要设定一个假设 – 我们所有ThoughtWorker是一个团队。在不同的场景下,由于要完成各种各样的任务,我们又会或长期或短期地组成相对更小的团队。在1993年3月Harvard Business Review有一篇文章“The Discipline of Teams”对团队作了一个颇为冗长的定义 –

“a team is a small number of people with complementary skills who committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable.”

如果从这句话里摘出几个关键词,那就是:

  • 共同使命( common purpose)
  • 互补的技能(complementary skills)
  • 绩效目标(performance goals)
  • 相互承担责任(hold themselves mutually accountable)

共同使命的重要性自不必冗述,我们来看看个人和共同使命之间的关系。当我们选择加入一个团队,必然始于个人的某些诉求。这个诉求可以是能力的成长、阅历视野的拓展,或是做出一番什么成就,以至于改变行业和社会,也可以是个人财富的增长,生活水平的提高,又或仅仅是自由宽松的工作环境。

判断成员和团队是否匹配的一个依据,是看在为共同使命所设计的框架下能否达成其个人诉求。这也就是我们在ThoughtWorks常听到的一个词 – Alignment。如果出现了不匹配的状况,并不一定是诉求和使命孰对孰错,可能只是不匹配了而已,尝试调节或是再做选择就是。

使命一般很难依靠单独一人或一类人达成,需要依据任务类型和所需经验技能的差异,定义一些不同的角色,就是所谓的专业化分工。在ThoughtWorks历史上,专业化分工也曾算是个敏感词。有人曰“能者无所不能”,又有人曰“术业有专攻”。一种声音是要废了xx角色,所有人都要全功能,又有一种声音是要发展领域专家,才能领先行业。吧台前、饭桌上、邮件里,都曾上演种种狗血的辩论剧情。但是不管对专业分工的观点如何,ThoughtWorks内部事实上已经出现了各种角色,有的是参考行业内其它公司的定义,也有不少是ThoughtWorks在摸索中衍生创建的。我们共同使命的实现依赖于这些角色的协作。

绩效目标则既是团队所有人对外的共同承诺,也是团队对自己的期望。检验绩效目标的达成状况,不仅能够验证我们是否走在正确的路上,更成为持续改进的基础。一旦目标设定,团队成员个体之间就要相互承担责任,否则我们常提倡的“集体责任制(collective ownership)”就会变成“谁也不负责任”(no ownership)。

以往做国内市场规划的时候,一般是我跟销售总监在小黑屋里一通密谋,拍脑袋得出不同类型服务和总体的营收目标。对照前面团队的定义,我意识到这方式存在着明显的问题:这是大家认可的绩效目标吗?参与的各个角色认为自己属于同一个团队吗?大家有意愿对这样的目标相互承担责任吗?琢磨了半天,我的答案是:不一定,不一(guan)定(xin),不一(ke)定(neng)。

既然发现了问题,就得想办法解决。我要设计一个机制,让参与实现目标的不同角色形成共识,在执行中相互负责。这时想到几年前看到的一篇文章“First, Let’s Fire All the Managers”,说的是一家番茄制品供应商的案例,文中提到个人和团队在没有经理角色的组织里如何领取并履行职责。他们使用的一个工具叫做Colleague Letter of Understanding (CLOU),我称其为同事谅解备忘录。方法就是让有关联的团队和个人之间相互协商,识别出未来一段时间里各自的活动领域,以及相应的成功衡量方式,然后写进这个谅解备忘录里。

对,就是这样。我也要搞一个这样的东西,先在销售和研发人员之间试试。不过如果等到年底再做,要是各方谈崩了,那明年中国区计划不就泡汤了。所以我打算提前一个季度开始做,万一不行,年底还有机会换个招儿卷土重来。

于是,趁着2014 China Away Day(一个让ThoughtWorker齐聚一堂的日子),我提前集结了销售团队、零售团队、XD团队的代表,加上交付业务的负责人。用了整整大半天的时间,把他们关在西安office的一个大会议室。我去开其它的会了,所以也不太清楚这过程中发生了什么,反正最后他们拿出的结果还算让人满意,从会议室出来的时候每个人看上去也算完整。大家对12个月的规划和达成条件形成了一个初步的共识,约定每个季度回顾和调整一次。

有了目标之后,我们这帮人应该怎样在执行当中体现共同使命和相互责任呢?过去的争议经常聚焦在两点:行为过界和未能充分履行自己责任。摘录一段在小范围讨(chao)论(jia)时我发的邮件,权作我对此的看法。这里只取了结论部分,去掉了血腥的上下文,有兴趣的可以套用各种身边角色冲突事件自行脑补。

“XX和YY不应该是一种甲方、乙方的关系,而应该是为共同目标负责的整体团队。一个团队的建立首先是accountability的划分。各个角色都有自己的专长,自然在这个团队中对各自行为产生的结果就有相应不同的期望,并为此承担责任。然后则是协作机制的建立。虽然我们每个人在自己负责领域都能够并且应该做出决策,但并不意味着决策过程是一个人在小黑屋里拍拍脑袋做出判断,然后对其他成员仅仅是通知、执行。除了紧急的行动(这也需要执行后的知会和收集反馈),主要决策应该在团队内部有个协商和听取意见的过程。”

自主行动的意愿很大程度上取决于当事人是否能影响事情的决策,在合作关系中,挫败感一个主要来源就是缺乏影响力。在信息链处于相对后端的角色常觉得自己处于劣势。我自己在做项目的时候,也曾因信息不对称难以影响onsite团队而苦恼,也曾抱怨销售安排接触客户高层时太过谨慎。

但后来发现,在ThoughtWorks只要愿意主动获取信息,一般没有遭到拒绝的可能,如果事先充分准备和交流,销售其实很愿意创造机会展现我们的优势。影响力是等不来的,是自己挣来的。跟影响力密切关联的有一个词叫“担当”。所谓担当就是关心、担心结果成败,并能为之费心费力。如果能做到比他人先想一步,多做一步,自然就会赢得主动,影响决策的过程。那么我们为什么不主动一点呢?

写在最后

人是复杂的生物,社会是复杂的系统,简单抽象出来的方案从来都不可能完美地解决复杂的系统问题。自主行动和主动承担责任在我们这样的组织中必然就不是黑与白的简单问题,探索中纷争和挫败感不可避免。负能量的抱怨和攻击只能在我们周围筑起一面面防卫的高墙,如果我们不想被高墙围绕,唯有大家都积极发起建设性的反馈和建议。


编者按:管理层如何从更高角度观察内部团队及个人间的交互,从而对照组织内部的机制运行状态,寻求更积极的改进,而不是片面的奖惩,是组织积极健康发展的必要条件。


更多精彩洞见,请关注微信公众号:思特沃克

Share

ThoughtWorks扁平组织的成长和归属感

最近有同事和一些离开我们的同事都提到,现在公司大了,归属感在降低,文化在稀释。ThoughtWorks中国正在面临着成长的烦恼。不少同事担忧,我们是不是为了成长而付出了太大的代价。

归属感的来源主要有两个,一个是共同的使命,一个是我们之间的亲密感。共同的使命不太容易因为成长而受到影响,而亲密感则确实有可能随着组织的扩大而被稀释。很多企业经过了创业阶段后就会面临这样的情况。很多人认为这是企业升级的必然,是实现管理正规化的机会,是用法制代替人治在企业里的体现。但是这其实不是必然,不同文化、不同风格的组织,成长的路径也会不同。ThoughtWorks是否有可能避免这样的宿命呢?

为什么小型的组织更有归属感和亲密感呢?就从ThoughtWorks中国区自己的历史开始吧。在我刚加入的时候,中国office(当时虽然有西安和北京两个小office,但大家都自称中国office)还只有20多人,但我也没有在一开始就感觉到什么归属感。

作为刚进公司的PM,我被要求启动一个新的海外交付项目,技术栈是.NET。团队包括一个不会.NET的Dev,一个面试Dev失败但通过了BA面试的BA,还有一个尴尬发现自己进了一个号称不需要manager的环境的manager(我)。这时候中国office刚开始了第一个大型的offshore交付项目。项目上集中了所有的老员工,还有一帮从海外过来支援的大人物。除了运营团队的几个人,这间办公室里其实就这两个项目团队。头几个月两个团队之间交流实在不多。那帮家伙每天冷眼旁观我们几个新人每天加班到十点半,也没见有人来搭个手。我们也没觉得跟那帮整天开会乱喷架构没见出什么活儿的家伙是一伙儿的。

归属感是什么时候产生的呢?那就是总是在同一个战壕里加班,肆无忌惮地挑战对方的观点(注:就事论事而非抬杠或攻击),周末去team building,分享很多个人和家庭琐事,互相起昵称,甚至有自己团队专属的语言和词汇。一开始这仅仅局限在一个项目团队内部,后来时间长了,一个人数不多的办公室里,大多数人也都能有机会共享这样的经历,归属感自然就产生了。

当一个办公室人数多了的时候,问题出现在什么地方?

首先我们没有办法跟周围所有人都有共享的经历,因此注定没法跟所有人产生这样的亲密感。当周围晃动的大多是不太熟悉的面孔时,自然而然会有情感甚至文化稀释的感觉。另外可能更重要的是,当人多了,层级似乎就不可避免地出现了。很多组织上的决定,政策的出台,甚至自己和项目的安排,既不是来自自己,也不是来自身边相熟相知的人,而是某一帮所谓的上面的“领导”。

要解决这样的问题,我们可以从建立一个相对稳定的较小规模团队开始。同时,鼓励团队承担责任,并给与跟责任相匹配的自主权,让团队在一个规则框架下尽可能少地被干预。

在一个公司里,跟业务密切相关的团队相对更容易形成稳定有内聚力的组织,比如现在已经有了的除了功能团队,业务团队有咨询团队、国内交付团队、海外交付团队,数据和TOC正在形成当中,而以兴趣爱好甚至专业方向聚集起来的松散组织,比如QA、BA、Dev等技术社区,很大程度上依赖于核心组织者燃烧着的热情,从机制上来讲,持续性和内聚力就要弱得多。

那么对于一个大型的办公室来说,什么样的机制能形成类似的效果呢?这让我想起了哈利波特里的霍格沃茨魔法学校(Hogwarts School of Witchcraft and Wizardry ),以及其四大学院 – 格兰芬多(Gryffindor),赫奇帕奇(Hufflepuff),拉文克劳(Ravenclaw),斯莱特林(Slytherin)。我们为什么不能在一个office内部形成多个学院呢?

之所以使用学院这个隐喻(Metaphor),是因为这个划分的单元既不同于职能部门,也不同于包括一个公司完整价值链的业务单元,而是专注于能力、研究和创新的一个组织,看上去更像是一所大学。

比如每当一个学院的人数超过几十人,我们可以就派生出新的学院。这个新的学院可能是原来的学院一分为二,也可以是由一个选拔出来的种子团队发展而成。Office Principal则像是Head Master的角色。

各个学院应该独自冠名,比如Gryffindor听上去就还不错。学院之间则可以形成不同的特色,而学院之内的同学们应该能够有机会获得很多共同的经历。当然,更详细的细节还有待讨论,比如具体的运营模式,领导团队的协作模式等。


更多精彩洞见,请关注微信公众号:思特沃克

Share