扁平化管理已经满足不了高科技企业硅谷正忙着干掉

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