-
调整职能
硅谷悄然而起的流行：在管理上干掉CEO！
虎嗅注：本文系 Medium 于 2015 年 5 月 27 日举办的一次论坛活动回顾，在该活动上，员工嘉宾 Daryl Koopersmith 和 Jean Hsu 进行了关于“无差异自治”(Holacracy) 工作方式的分享演讲。
关于Holacracy，之前有的媒体翻译为“合弄制”、或者“无领导管理方式”，其本质是一种基于公司任务的管理模式，而不是传统公司采取的标准的层层报告的管理模式，它强调更加民主、相互交集且自我管理。从这篇来自Medium员工的分享里，我们惊讶地发现当他们长篇累牍地谈论公司管理与增长时，“CEO”这个词没有出现一次。这或许也是“无差异自治”的一个重要特点——从某种程度上，是要在管理上消灭CEO，或者让TA变得不再那么必要、不再无处不在。
此前虎嗅曾报道过Zappos的谢家华是如何激进地在他的公司里推进该管理。今天我们来看这几年成长起来的新兴博客平台Medium是怎么做的。Medium最近融了5700万美元，估值据说达4亿美元。
无差异自治（Holacracy）是针对组织及其员工的一套工具。在如今的企业当中，职能角色全部都被定义好了，每一个职能都具有一定的职责和权威性。这意味着处于“顶层”的人并不具有彻底的权威——尽管是层级化的，但是权威仍旧是分散的。人们也可以具有多种职能，且每个人都能看到其他雇员的职能是什么。
“无差异自治”拥抱变革，期望变革，在 Medium 的活动上，嘉宾分享了 Medium 的组织结构如何变化，以支持工程团队规模的增加。
团队起先的结构很简单，工程师以小规模的跨职能团队形式进行工作——工程师、设计师、产品经理等等——称之为产品启动群 (在无差异自治中表示为圈子)。
不断进化
随着团队的扩大，为了追踪工程师的项目进度，需要有一个更固定的专用空间，更加明晰的支持架构，以便于让工程师讨论项目相关的问题。为了满足这一需要，工程师圈被提出，并且得到了建立。
在这个圈子里，包含试制工程师 (Proto Engineer) 职能，全部由新聘请的工程师担任，还包含工程师、技术负责人 (Tech Lead) 职能。每一个职能都有详细的明确职责，规定负责的人要做什么。大部分工程师在核心工程圈和产品圈均要承担职能。但是也可能出现一个工程师负担许多职能的情况，比如技术运营 (Tech Ops)——在工程圈包含之内，四个工程师要肩负上百万种职能。对于一个规模较小但是负责工程师团队许多重要环节的圈子来说，他们要做的任务量有点夸张——而且每一项都要执行得很好，这一点令人印象深刻。
在工程师团队达到 20 人左右的时候，工程师团队负责人已经显然无法做到与所有人保持常规一对一面谈的状态 (常规状态下每隔几个月要见一次以上)。随着员工们在工作职能间的切换、各自产品圈中有不同负责人，需要有一个可以扩大规模的管理方式，让每一个工程师都能够和某个同事建立长期的关系，探讨个人成长、职业生涯轨迹和日常工作中的棘手情况。
Medium 团队起用了“小组领导”(Group Lead) 的职能，即我们所认为工程师管理的“人际方面”(people side)。明确这个职能的人不是“技术领导”(Tech Lead)，即负责工程师管理中的“技术方面”(technical side)的角色，也不是“项目牵头人”(Initiative Lead)，即类似于产品经理的角色。“小组领导”是工程师保持常规一对一会面的人。
员工和职能
和传统架构的公司相比，这种做法最大的区别是，你不仅只是负责一个职能，一条路径发展下去。员工和职能是分离的，所以你可以拥有一条“自我选择”(choose-your-own-adventure) 的职业路径。
举个例子，Jean 是 Medium 的一位工程师，但是她又同时肩负多种不同的职能，其中包括 11 位工程师的“小组领导”、产品 Node Services Guild 的负责人、Publications Initiative 的工程师等等。她还帮助工程师圈子搭建入职和面试培训，以及招聘和外联等等。将这些职能明确地分配给 Jean 对她很有好处，因为这些职责很重要，但是却经常被忽视，或者被认为是会让工程师分心的工作。
Jean 本人很享受这种明晰的管理结构，且不觉得她一定要选择是否完成 100% 的管理目标，她认为许多公司都是后一种情况。她能挑选自己希望专注的目标，每个月都可以不同。有时，她可能希望专注在组织领导力上，过几个月，她可能希望在基础设施项目上投入，或是发起一个项目在技术上挑战自己。
肩负不同的职能
工程师 Koop 谈到他在 Medium 负责多个职能时，这样说道：
Medium 的每个员工都是这个组织的某一个独一无二的部分，从各自的职能中能够反映出来。
和我们大部分的应用开发工程师一样，当 Koop 于 2013 年 3 月份加入 Medium 的时候，他被赋予两个职责：一个是工程师，一个是某产品的贡献者。随着工程师团队的扩大，团队意识到需要为代码库核心区域安排一个维护者。为了满足这一需求，工程师团队 2013 年末设立了 Domain Expert 这个职能，专注于维护 Medium 的 web 框架。随着时间的过去，他在工程师圈里负责了许多不同的职能，与此同时也要肩负起工程师的职责。
不是每一个人都要负担许多职责。一些人有一个或两个职责，专注在他们的工作上，另一些人则会有更多职责。有时候，在某个时间里，满足所有的职责很难 （甚至是不可能的）。
除此之外，公司里的每个人都有权利将各自的职责做优先级排列。优先级可能会改变，和你的同事及时沟通你所专注投入的事情，始终是很重要的。
随公司需求调整职能
每个人都有权利提议改变 Medium 的工作方式。比如在 2014 年末的时候，工程师们发现 Domain Expert 职能变得有点不那么准确了。在现实中，随着机构规模的扩大，一名员工无法完全管理代码库的某个区域。取而代之的是一组工程师——Domain Expert 和其他员工——一起协作来维持并改进 Medium 代码的不同区域。在一次会议中，工程师 Koop 提议，将 Domain Expert 的职能改进为几个“小组织”(Guild)，以便于反映出工程师团队是怎么运作的。
目前 Medium 有四个 Guilds：Web 客户端、iOS、节点服务 (Node Services) 和数据。每个小组织都专注在改进各自的主旨、建立最佳工程实施以及培训其他团队成员上面。小组织以团队需要为标准来对工作进行优先级排序。其中一些专注在开发者生产力上，另一些则专注在教育和最优实施方法上。
Medium 目前的工程师架构是提议积累实施的结果。眼下市场上大部分组织架构都是死板的，并没有为变化和增长进行设计。这常常会导致大规模的、颠覆性的组织重构。“无差异自治”让 Medium 能够不断优化，不断调节组织以便于贴近需求，随着 Medium 的增长，这一点仍将继续。
并没有解决所有问题
Medium 还没有搞清楚所有问题。“无差异自治”是 Medium 改变组织的工具。随着团队的增长，将会面临更多的挑战。一个综合性的等级系统是怎样的？如何能实现频繁有效的个体反馈？大部分公司都面临这些问题 (无论它们是否真的试图解决这些问题)。Medium 希望从它们的成功和失败中学习，而不希望重蹈覆辙。
好的工程师管理很重要
在硅谷目前有一个很盛行的趋势，那就是大家都在推崇——公司管理要尽量少的理念，或者是无管理者的扁平架构理念。但是活动嘉宾 Cathy Edwards 认为，好的管理是公司成功的关键。好的管理能够将政治斗争最小化，确保员工的幸福感和成长性，为整个团队的生产力最大化提供适佳的环境。但是大部分被提拔至管理岗位的人从未被告知他们的工作究竟是什么，也没有经过培训，所以他们往往无法实现目标承诺。
Cathy 认同“无差异自治”做法的其中一点，是这种管理方式使得许多管理职能明晰化，让谁负责做什么事情一目了然。虽然并非十全十美，但是采用“无差异自治”的组织并不认为层级式管理架构注定失败。让公司整个团队都能够投身其中，各司其职，在公司架构和流程上做好决策，能够帮助确保这种管理方式对所有人都有效，从本文之前的叙述来看，“无差异自治”在 Medium 发挥得很好。
本文来源：Medium，虎嗅编译。
扫一扫 加微信
hrtechchina
