做 CEO 要避免理性的自负（2017 码荟演讲）

A CEO Must Avoid the Conceit of Reason (2017 Code Club Speech)

> By Zhang Yiming · speech at Source Code Capital's 2017 Code Club (码荟) · Source Code Capital website (the organizer's page) · 2017-04-24 · [Original link](https://sourcecodecap.com/code-class-post/zhangyimingzuoceoyaobimianlixingdezifu/)

At Source Code Capital's annual meeting last year, I talked about hiring excellent people as much as possible. Once excellent people are gathered together, how should things be done? That's what I want to share this year: how to build an effective organization, and how to meet the management challenges as a company grows from small to large. These are also questions we often discussed and thought about as Toutiao grew. At present, we lean toward the solution of "Context, not Control".

Let me use an analogy to explain the difference between Context and Control.

Computers have two ways of handling tasks. One is the supercomputer, using one computer to handle very intensive tasks; the other is distributed computing, having many machines handle tasks together, breaking down the task and breaking down the resources the task needs. There are two modes of company management that resemble these two ways of computing.

The first treats the CEO as a supercomputer. The CEO designs the strategy and proposes a strategic plan, which is broken down level by level and executed. If something comes up during execution, it's reported upward again, the CEO aggregates the information and sets work tasks again. In this process there are approvals, processes and many management mechanisms. Many companies in the past took this approach, which mainly consists of constructing strategy and controlling processes.

The second has more people take part in decisions and lets more ideas emerge from the bottom up, rather than a top-down breakdown of strategy. In this process more people need to make judgments based on Context, rather than executing according to instructions.

Concretely, what is Context and what is Control? Context means the set of information needed for a decision, including what the principles are, what the market environment is like, what the overall industry landscape is, what the priorities are, to what degree something needs to be done, as well as business data, financial data and so on. Control includes committees, instructions, breakdown and aggregation, processes, approvals and so on. Why do we lean toward "Context, not Control"?

In our view, Control often brings some dangers. When humans judge their own capacity for rational control they have an illusion, and this is especially true of smart, rational people, who often harbor a conceit of reason. CEOs often have past success, especially success in the company's early days, and a CEO has no superior and is seldom challenged, so it's easy to think yourself brilliant and mighty. But people overlook one thing: the industry keeps developing, and although your knowledge is rich, it is still limited amid the industry's constant change.

Sometimes CEOs mistakenly believe the methodology they've proposed is especially good and the model especially elegant, and want to execute it, or roll it out across the whole company, but they ignore the gap between abstract knowledge and concrete form. Reason is often suited only to abstracting knowledge; for solving concrete problems it may not really help. Of course we don't deny the role of reason; we just want to avoid the danger of over-amplifying reason. Grand top-down strategies are often disasters, and there have been quite a few real examples in the industry.

Take Windows Vista. This project was pushed hard by Bill Gates according to his own technical philosophy, putting forward a series of grand ideas, with a planned launch in 2003. These theories all sounded very good and very advanced, but it didn't really launch until 2006; in between it was rebuilt once, the goals were lowered and the plan revised, and only then was Vista finally shipped. Jobs made the same mistake. When he first left Apple to do NeXT, he proposed a very idealized model for making computers, including an elegant operating system and a fully object-oriented (Object Oriented) language, but in the end it didn't sell many units. China has examples like this too: Shanda's 易宝 (Yibao) concept was also grand, but it didn't match the situation at the time, whether the entertainment industry, internet bandwidth or the policy environment, so in the end it failed.

Besides the strategic problems Control brings, the pursuit of a sense of control also makes companies slow to react. Everyone here is a CEO; we can add up expenses, contracts and offers and count how many approvals there are each day. Suppose it's 15 a day; that's more than 5000 a year. How many of these are truly effective, and how many have been seriously thought through? Or does it exist purely for the sense of control? As if by approving expenses, the money won't be misused. By comparison, could your subordinates or other people approve them better? I think so, because they make decisions on the front line and have fuller external information. Because the CEO's energy is limited, a large number of approval delays add one to two days to many things for no reason.

In response to these problems that appear once a company gets bigger, there's a wrong solution: premature BU-ization. But this approach leads to several problems:

First, departments don't cooperate. For example, if a BU handles its own PR crises and hires its own engineers, it doesn't need to go to marketing or technology colleagues, so departments don't need to cooperate, or rather cooperation gets worse, because nobody puts effort into working things out together.

Second, redundancy within departments and declining professionalism. For example, the engineers a single BU hires aren't held to a high enough standard, and the engineering team isn't big enough, so there's not enough mutual learning and improvement, professionalism declines, and things become redundant internally. For the CEO, it feels more like being a contractor: I've handed out this task, do it yourself, I'm not involved in the process, I only want results. Over time, the company culture deteriorates.

Of course there are exceptions. If a business is relatively independent or very mature and truly doesn't need internal support and cooperation, it can be made into a BU. The point of a company's existence is division of labor and cooperation; for business activities within the company, we must make sure internal cooperation (合作合作) costs are lower than market transaction costs. A large number of non-cooperating BUs essentially shouldn't exist inside the company. Premature BU-ization is a fairly common wrong solution. Many companies set up many subsidiaries too early, or split into many project teams, or go further and spin businesses off to raise money independently. In my view these are often not very good solutions but lazy ones, so that you don't have to solve cooperation and communication problems. [Translator's note: the source repeats 合作合作 ("cooperation cooperation"), apparently a typo; translated once.]

Compared with Control, what are the benefits of a management mode that stresses Context?

First, distributed computing. Letting more people use more CPUs to compute, letting more people take part in decisions, using collective wisdom. As management, you spend only 30 seconds on an approval decision, but someone else can spend three hours and judge after doing more research.

Second, faster execution. No need for level-by-level aggregation, no need to aggregate in one place, no need to queue at the CEO; you can respond more promptly.

Third, full external information input. In the Control mode, all information has to reach the CEO node and rely on the CEO to distribute it again. The CEO largely becomes the interface between the company and the outside. Compared with relying solely on the CEO to engage with the outside, understand the market and industry or the macroeconomy, letting more colleagues and more managers face the industry directly will certainly make information fuller, and the angles different too.

Fourth, a sense of participation sparks creativity. Doing the same thing, if employees know both what and why, it's more interesting than only knowing the instructions. This helps bring out employees' creativity.

Fifth, scalability. Building Context may take the form of internal systems or knowledge-sharing documents, all of which can be reused and are scalable. The time and energy of the CEO and the management team have a bottleneck; solving things by straining physical strength, brainpower and endurance has a bottleneck and has no economies of scale.

Of course, sometimes Control is also needed:

First, emergencies and key projects. For example, a major PR crisis needs a fast response. Key projects too: if a competitor is already closing in (逼进), distributed discussion and bottom-up emergence at that point can't solve the problem in time, and the window passes quickly, so emergencies and key projects need Control. [Translator's note: the source writes 逼进, probably for 逼近 "closing in"; translated by the likely meaning.]

Second, innovative businesses and the early days of new departments. If a department is newly set up, or a new executive has just taken office and hasn't yet worked things out with the company, Control is needed then. In the early days of an innovative business, when more support and resources are needed, unified coordination by the CEO leading the progress is also needed.

Third, mismatched role assignments. If the person in some role is far from the company's philosophy, their superior also needs Control to intervene.

Why does this problem appear after a company has developed for a while, and not in the company's early days?

Because in a company's early days, the CEO is generally the expert on the business. The business is simple and the industry situation is simple, so the CEO can just make the decisions himself, which is efficient. But as the company grows, the CEO's energy is scattered by many things, PR, fundraising, external events and so on, and the organization itself also consumes a lot of managers' energy. In addition, the environment becomes complex and the business diversifies; the CEO is no longer the expert, and is not even the most sensitive person to the business anymore. We ask CEOs to learn and grow fast, so the supercomputer gets stronger and stronger and its knowledge broader and broader, but a person's energy is always limited, and there are always many respects in which they're not as good as in the startup stage. Twenty years ago Bill Gates was an excellent architect; twenty-odd years later, still using his ideas to guide whole large projects has very limited effect. Of course some companies don't have this problem, because their industry is stable with little innovation, and following traditional processes is enough, like Lao Gan Ma chili sauce. To sum up, we think a good organization includes:

First, excellent people. It needs distributed processors, not just one executor; every distributed computer has judgment and must be smart.

Second, a management mode of "full Context, little Control". Everyone has the role they need to play, holds all the contextual information and makes business decisions, with a little intervention when necessary. With these two points, you can ensure the transaction costs inside the organization are minimized and make high-quality decisions. Based on this philosophy, at our company, when we hit a problem, we're often in the habit of first asking whether the Context is insufficient, rather than adding Control.

For example, if some piece of progress goes wrong, we don't first consider having someone more senior do it, but think the other way: is the Context insufficient, did we fail to share with him the industry situation, the business data, past failure cases?

As a manager, think about whether you make better decisions than others because of ability or because your context is fuller, and whether there's information asymmetry. If you observe carefully, you'll find managers sometimes even use information asymmetry to show their own value. So within the company, the foundational project of building Context must be done well first, but this isn't easy; it takes a great deal of communication, management, and product and technology work. At the practical level, we've done some things, which I'll share with you:

First, reduce rules and approvals. Departments are not allowed to issue rules casually. Even if there must be rules, we want them to be very simple; rules that run several pages and are very hard to execute aren't allowed. Reduce approvals, and even, ideally, have no approvals at all.

Second, flexible organizational structure, rejecting territorial mindsets, being able to adjust reporting lines flexibly. Make everyone realize that reporting lines are just one way of aggregating information, and can be adjusted at any time as the business needs. If we have a project that's very important, we may need marketing colleagues to all support this project, and during that time the head of this project is also the head of the marketing colleagues.

Third, de-emphasize hierarchy and titles. We encourage young people to put forward more ideas. I first became a CEO at 26, and I believe the 26-year-olds at our company have very good practical experience and a very good education; as long as they're given good context, they can also make good decisions. To keep formality from suppressing grassroots nodes, we de-emphasize hierarchy. First, these forms of address aren't allowed: "Boss" (老大), "Mr./Ms. So-and-so" (某某总), "Teacher" (老师). Once such forms of address appear, many ideas can't emerge. People may tend to first hear what "Teacher" thinks and not speak up first themselves. We have no day-to-day visible differences in treatment that come with titles, such as what kind of person gets what kind of computer, or what kind of desk; that would also create a sense of hierarchy and affect different colleagues' willingness to express opinions.

Fourth, we encourage internal information transparency. We encourage group chats and full communication between departments, not just communicating with the CEO. We also don't advocate one-on-one communication; we think one-on-one communication is very inefficient. If a newly joined colleague or executive wants to communicate with me one-on-one, I often say you can cc me, but first send it to other people, to the people you need to work with.

We keep management's OKRs open to their subordinates, so everyone knows what you're doing, why you're doing it, and what people in other departments are doing. Setting OKRs also isn't a top-down breakdown; people align with each other themselves. Look at your superior's OKRs, look at other departments' OKRs, look at peers' OKRs, understand what the company's most important tasks are now, what the most important tasks are this quarter, and what I can do to help them. Quarterly meetings also try to involve as many relevant people as possible, not a very small executive meeting. We also often hold CEO face-to-face sessions, answering employees' questions at these meetings so everyone understands the company's progress.

Fifth, we believe fully building context requires good internal systems for support. We have an internal tools development team of nearly 100 people, trying all kinds of tools. For example, we developed our own OKR system and connected it with the IM we use internally, making it easy for everyone to look each other up.

These basic tools, first, make people's lives easier, and second, can scale. When new people join the company, they quickly get used to the OKR system and can quickly see internal materials and get information from inside. They also realize that they don't only have the right to obtain information, but also the responsibility to support related work. In our view, this kind of practice is building the company as a product, making context within the company more effective, and making this system's distributed processing capacity stronger.

Copyright: © LookMinds. Our own edited text and translation, not a substitute for the original; rights in the original belong to the author and the platform. Please see the original link.