來源：經濟學聚焦，作者：張一鳴
作為一家2012年成立的公司，字節跳動無疑是互聯網的“新手”。
然而，沒有人會想到，僅僅十年不到的時間，字節跳動已經成為如今互聯網界的新傳奇和新“巨獸”。
從不起眼，到使所有人不得不看見，字節跳動怎么做到的？
下面分享的是字節跳動創始人、CEO張一鳴的一篇經典演講《做CEO要避免理性的自負》，全文如下：
去年源碼資本的年會，我講了要盡可能招優秀的人。把優秀的人聚集起來之后，該怎么做事情呢。這是我今年想分享的內容。
怎么建立一個有效的組織，怎么在公司從小變大的過程中，應對管理上面臨的挑戰。這也是在成長過程中，我們常常討論和思考的問題。現在，我們傾向于“Context，not Control”的解決方案。
打個比方，來解釋Context和Control的區別。
計算機有兩種處理任務的方式：一種是超級計算機，用一臺計算機處理很密集的任務；一種是分布式的運算，讓很多機器共同來處理任務，把任務分解，把任務所需要的資源分解。
有兩種企業管理的模式分別跟這兩種運算方式類似。
第一種，把CEO當成超級計算機，CEO做戰略設計，提出戰略計劃，逐層分解之后執行，執行的過程中如果遇到情況，會再往上匯報，CEO匯總信息，再次定出工作任務，這個過程中有審批、有流程，有很多的管理機制。過去很多企業都是采取這樣的方式，主要包括：建構戰略和控制流程。
第二種，有更多的人參與決策，讓更多的想法自下往上涌現出來，而不是一個從上到下的戰略分解，這個過程中需要更多人基于上下文Context做出判斷，而不是根據指令來執行。
具體來講，什么是Context，什么是Control。
Context是指決策所需要的信息集合，包括原理是什么，市場環境如何，整個行業格局如何，優先級是什么，需要做到什么程度，以及業務數據和財務數據等等。
Control則包括了委員會、指令、分解和匯總、流程、審批等等。
為什么我們傾向于“Context，not Control”呢?
在我們看來，Control往往會帶來一些危險。人類在判斷自己的理性控制能力時會有一種幻覺，對于聰明理性的人更是如此，常抱有理性的自負。
CEO們往往有過成功的經驗，尤其在公司早期成功過，且CEO沒有上級，很少被人challenge，容易覺得自己英明神武。
但是大家忽視了一點，行業是不斷發展的，你所具有的知識雖然豐富，但在行業不斷變化中依舊是有限的。
有時候，CEO們會誤以為，自己提出的方法論特別好，模型特別優雅，希望把它執行，或者在全公司大范圍內推行，但忽略了抽象知識和具體形式之間有差距。
理性往往只適合做知識抽象，對具體問題的解決，不一定真的有幫助。當然我們并不要否定理性的作用，只是要避免過度放大理性帶來的危險。
自上而下的宏大戰略往往都是災難，業界也發生過不少真實的例子：
比如windows vista，這個項目是比爾蓋茨按自己技術理念力推的，提了一系列的宏大理念，計劃2003年上線。這些理論聽起來都非常好，非常領先，但是一直到2006年才真正上線，中間還重構了一次，把目標降低，重新修改了計劃，最終才把Vista推出去。
喬布斯也犯過同樣的錯誤。第一次離開蘋果做NeXT的時候，他提出一個非常理想的做計算機的模式，包括優雅的操作系統，完全面向對象（Object Oriented）的語言，但是最終也沒有賣出多少臺。
中國也有這樣的例子，曾經盛大易寶的理念也很宏大，但和當時無論是文娛行業、互聯網帶寬，還是政策環境的情況都不匹配，所以最后失敗。
Control除了會帶來戰略上的問題，還會因為追求控制感而導致企業反應遲鈍。
在座的都是CEO，我們可以把支出、合同、offer，全部加起來算算每天的審批有多少。假設一天是15個的話，一年就是5000多個。
這其中真正有效的有多少，經過大家認真思考的有多少？還是它的存在純粹基于控制感？好像做了支出審批，資金就不會被亂使用。
相較而言，你的下屬或者其他人是不是能夠更好地審批？我想是的，因為他們在一線決策，有更充分的外部信息。由于CEO精力有限，大量的審批延時，讓很多事情平白增加了一天到兩天的時長。
針對公司變大后，會出現的這些問題，有一種錯誤的解決方案——過早BU化。這種方案會導致幾個問題：
第一，部門間不配合。比如說，BU自己處理PR危機，自己招工程師，就不用找市場或技術同事了，部門之間就不用配合，或者說會導致配合變得更差了，因為不花心思磨合了。
第二，部門內冗余，專業度變差。比如說，單個BU招的工程師標準不夠高，而且工程師團隊規模不夠大，互相學習不夠，進步提升不夠，專業程度變差，內部也變冗余。對于CEO來說，感覺更像承包者，我把這個任務發出去了，你自己做吧，我不參與過程，我只要結果。長此以往，企業文化就變差了。
當然有一些例外，如果是相對獨立或非常成熟的業務，確實不需要公司內部支持和配合，可以BU化。
公司存在的意義就是為了分工和配合，公司內的業務活動，要確保內部合作成本低于市場交易成本。大量不配合的BU，本質就不應該存在于企業內部。
過早BU化是一種比較普遍的錯誤解決方案。很多公司過早成立很多子公司，或者拆成很多項目組，甚至更進一步把業務獨立出去，獨立融資。
在我看來，這些往往都不是好的解決方案，而是懶惰的解決方案，如此就不用解決配合和溝通問題了。
相比Control，強調Context的管理模式有什么好處？
第一，分布式運算，讓更多人用更多CPU進行運算，讓更多人參與決策，利用集體的智慧。作為管理層，你做審批決策只花30秒，但別人可以花三個小時，做更多的調研之后才判斷。
第二，可以更快速地執行。不需要層層匯總，不需要匯總到一處，不需要在CEO這里排隊列，能夠更及時地響應。
第三，充分的外部信息輸入。在Control的模式中，任何信息都要到CEO這個節點，靠CEO再分發出去。CEO很大程度變成了公司和外部之間的接口。相比單靠CEO接觸外界情況，了解市場行業或者宏觀經濟，讓更多的同事，更多主管直接面向行業，信息肯定會更充分，角度也不一樣。
第四，參與感激發創造力。做同樣的事情，如果員工知其然，也知其所以然，會比只知道指令，做起來更有意思。這個對于發揮員工創造力是有幫助的。
第五，可規模化。Context的建設，表現形式可能是內部的系統，可能是知識共享文檔，這些都是可以復用的，是可規模化的。而CEO和管理團隊的時間精力有瓶頸，靠拼體力、腦力、耐力來解決，是有瓶頸的，是沒有規模效應的。
當然，有時候也需要Control：
一、緊急情況和重點項目。比如說重大的PR危機需要快速響應。重點項目也是如此，如果競爭對手已經逼進，這個時候進行分布式的討論，自下而上的涌現，來不及解決問題，時間窗口很快就過去了，所以緊急情況和處理重點項目需要Control。
二、創新業務和新部門的早期。如果一個部門新設立，或者一個新高管上任，還沒有跟公司磨合好，這個時候需要Control。創新業務早期，需要更多支持配備資源的時候，也需要CEO的統一協調，主導進展。
三、不匹配的職位安排。某個崗位的人跟公司理念差距很大，那么他的上級也是需要Control來干預的。
為什么公司發展一段時間后會出現這個問題，而公司早期不會出現？
因為在公司早期的時候，CEO一般都是業務的專家。公司業務簡單，行業情況簡單，CEO自己做決策就可以了，這樣效率高。
但隨著公司的成長，CEO精力被很多事情分散，PR、融資、外部活動等等，組織本身也非常消耗管理者精力。
另外，環境變復雜，業務多元化，CEO不再是專家，甚至對業務也不是最靈敏的人了。
我們要求CEO快速學習成長，超級計算機變得越來越強，知識面越來越廣，但是人的精力總是有限，總有很多方面是不如創業階段的時候。
比爾蓋茨20年前是一個優秀的架構師，20多年之后，還是要用他的理念來指導整個的大型項目，作用就非常有限了。
當然有些企業不存在這樣的問題，因為他們所處的行業穩定，創新較少，遵守好傳統的流程就可以了，比如說老干媽辣醬。
總結而言，我們認為好的組織包括：
一，優秀的人。
需要分布式的處理器，不只是一個執行者，每一臺分布式計算機都有判斷能力，都要聰明。
二，“充分Context，少量Control”的管理模式。
每個人有他需要扮演的角色，掌握所有的上下文信息，做出業務決策。在必要的時候，做出少量的干預。
有了以上兩點，就能保證組織內的交易成本最小，并且做出高質量的決策。
基于這個理念，在我們公司，遇到問題的時候，往往習慣先問Context是不是不夠充分，而不是增加Control。
比如說某項進展出了問題，我們首先不考慮讓更高階的人來做，而是反過來想，是不是Context不夠，是不是沒有把行業的情況、業務數據、過去的失敗案例分享給他。
作為管理者，要想想你作出比他人更好的決策，是因為能力還是你的context更充分，是不是存在信息不對稱？大家仔細觀察會發現，有時管理者甚至利用信息不對稱來體現自己的價值。所以，在公司內首先要把建設Context這個基礎工程做好了，然而這并不容易，需要大量的溝通、管理和產品技術工作。
從具體操作層面，我們做了一些實踐，分享給大家：
第一，減少規則和審批。
不允許部門隨便出規定，即便不得不有規則，我們也希望規則非常簡單，不允許有長達幾頁紙，非常難執行的規定。要減少審批，甚至希望盡量不要審批。
第二，組織結構靈活，拒絕領地意識，能靈活調整匯報關系。
讓大家意識到，匯報關系只是匯總信息一種方式，只要業務需要就可以隨時調整。
如果我們有一個項目非常重要，我們可能需要市場部的同事都支持這個項目，那在這段時間里，這個項目的主管也是市場部同事的主管。
第三，弱化層級跟title。
我們鼓勵年輕人多提想法。我第一次擔任CEO是26歲，我相信我們公司26歲的人有很好的實踐經驗，受過很好的教育，只要給他們好的context，他們也能做出好的決策。
為了避免形式感給基層節點帶來壓制，我們弱化層級，首先是不允許這種稱呼——“老大”、“某某總”、“老師”，這種稱呼一旦出來之后，很多想法就不能涌現出來了。他們可能會傾向于先聽聽“老師”有什么意見，自己不能先說出來。
我們沒有title帶來的日常可見的待遇區別，比如什么樣的人配備什么樣的電腦，什么樣的人配備什么樣的辦公桌，這樣也會帶來層級感，也會影響不同的同事發表意見。
第四，我們鼓勵內部信息透明。
我們鼓勵群聊，各部門之間充分溝通，不要只跟CEO溝通。也不提倡一對一的溝通，我們認為一對一的溝通效率很低。如果有新加入的同事或者高管希望跟我一對一的溝通，我經常會說你可以抄送給我，但你首先發給其他人，發給需要和你配合的人。
我們讓管理層的OKR對下屬員工保持公開，讓大家知道你在做什么，為什么在做這個事情，其他部門的人在做什么。
OKR的制定過程也不是自上而下的分解，而是大家互相之間自己對齊。看一下上級的OKR，看一下別的部門的OKR，看一下同級的OKR，了解目前公司最重要的任務是什么，這個季度最重要的任務是什么，我做什么能夠幫助他們。
季度會也是盡量讓相關人多參與，并不是一個非常小范圍的高管會。我們還會經常舉辦CEO面對面，在這個會上回答員工提問，讓大家了解公司進展。
第五，我們認為做到充分建立context，需要好的內部系統做支持。
我們有將近100個人的內部工具開發團隊，做各種工具嘗試。比如我們自己開發了OKR系統，并且和內部使用的IM打通，方便大家互相查看。
這些基礎工具，第一可以讓人更輕松，第二可以規模化。新人加入公司，很快能適應OKR系統，很快可以看到內部的資料，從內部獲取信息。
他也能意識到，他不僅僅有獲得信息的權利，也有支持相關工作的責任。這樣的實踐，在我們看來，是把公司當成產品來建設，讓公司內部的context更有效，讓這個系統分布式處理能力更強。
您的位置：
