Yiming Zhang: Avoid the Arrogance of Rationality as CEO | 2017 Source Code Capital Annual Meeting

"Context, not Control"

Every successful founder eventually faces the challenge of scaling from a small startup to a large organization. As both architect and steward, the CEO must constantly reinvent themselves to meet the management demands that come with growth.

At Source Code Capital's 2017 Ma Hui gathering, Yiming Zhang, founder and CEO of ByteDance, shared his hard-won management philosophy with fellow entrepreneurs at every stage: a CEO must guard against the arrogance of rationality.

The following is the full transcript of Yiming Zhang's speech at Source Code Capital's 2017 Ma Hui:

At last year's Source Code Capital annual meeting, I talked about hiring the best people possible. Once you've gathered exceptional talent, the question becomes: how do you actually work together? That's what I want to share this year — how to build an effective organization and how to tackle the management challenges that arise as a company grows from small to large. This is something we at ByteDance have discussed and wrestled with constantly throughout our growth. We've come to favor an approach we call "Context, not Control."

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

There are two ways computers process tasks: one is the supercomputer model, where a single machine handles computationally intensive work; the other is distributed computing, where many machines work together, breaking down tasks and the resources needed to complete them. These two approaches mirror two distinct models of corporate management.

The first treats the CEO as a supercomputer. The CEO designs strategy, proposes strategic plans, breaks them down layer by layer for execution. When issues arise during execution, teams report back up, the CEO synthesizes the information, issues new tasks, and the cycle repeats — with approvals, processes, and extensive management mechanisms along the way. Many companies have operated this way, focusing primarily on strategy architecture and process control.

The second model involves more people in decision-making, allowing more ideas to bubble up from below rather than cascading down from a top-level strategy decomposition. This requires more people to make judgments based on context rather than executing according to directives.

So what exactly are Context and Control?

Context is the full set of information needed for decision-making: the underlying principles, market conditions, competitive landscape, priorities, required standards, business data, financial data, and so on.

Control encompasses committees, directives, decomposition and aggregation, processes, approvals, and the like.

Why do we favor "Context, not Control"?

In our view, Control often brings serious risks. Humans have an illusion about their own rational control capabilities — and this is especially true for smart, rational people, who frequently fall prey to the arrogance of rationality. CEOs often have past successes under their belt, particularly in a company's early days, and since they have no boss and rarely face challenge, they can start to believe they're infallible. But what gets overlooked is that industries keep evolving. However extensive your knowledge, it remains limited against the backdrop of constant industry change.

Sometimes CEOs mistakenly believe their proposed methodology is brilliant, their model elegant, and they want to push it through or roll it out company-wide — ignoring the gap between abstract knowledge and concrete reality. Rationality is good for abstraction, but not necessarily for solving specific problems. We're not dismissing rationality's role, just warning against the dangers of inflating it.

Top-down grand strategies are usually disasters. There are plenty of real-world examples.

Take Windows Vista. Bill Gates pushed it through based on his own technical vision, laying out a series of grand concepts, with a planned 2003 launch. The theories all sounded excellent, even visionary. But it didn't actually ship until 2006, with a mid-course restructuring, lowered ambitions, and revised plans before Vista finally made it out. Steve Jobs made the same mistake. When he first left Apple to start NeXT, he proposed an idealized model for computing — an elegant operating system, a fully object-oriented language — but ultimately sold very few machines. There's a Chinese example too: Shanda Group once had grand visions for the Shanda EZ Pod, but it didn't match the realities of the entertainment industry, available internet bandwidth, or the policy environment at the time, so it failed.

Beyond strategic problems, Control also slows companies down by prioritizing the feeling of control over actual responsiveness. Everyone here is a CEO — add up your daily approvals for expenses, contracts, offers. If it's 15 a day, that's over 5,000 a year. How many of those are truly substantive? How many do you actually think through carefully? Or do they exist purely for the sense of control? As if approving expenses prevents misuse of funds. Could your subordinates or others approve them better? I think so — they're closer to the front lines, with better external information. Given limited CEO bandwidth, massive approval backlogs routinely add a day or two to everything.

There's a common wrong solution to these scaling problems — premature BU-ification.

But this creates several issues:

First, departments stop coordinating. If a business unit handles its own PR crises and recruits its own engineers, it doesn't need to work with marketing or engineering colleagues. Coordination atrophies because people stop investing in it.

Second, redundancy grows and expertise degrades within departments. A single BU might hire engineers to lower standards, and with teams too small for meaningful peer learning and growth, professional development suffers while internal redundancy increases. For the CEO, it feels more like contracting out — "I gave you the task, you handle it, I won't engage with the process, I just want results." Over time, company culture deteriorates.

There are exceptions: relatively independent or mature businesses that genuinely don't need internal support and coordination can be BU-ified. But the very purpose of a company is division of labor and coordination. Internal business activities must ensure that cooperation costs are lower than market transaction costs. A proliferation of uncoordinated BUs essentially shouldn't exist within the enterprise. Premature BU-ification is a widespread wrong solution. Many companies spin off subsidiaries, split into project teams, or even take things further with independent financing too early. In my view, these are usually lazy solutions — ways to avoid solving coordination and communication problems.

What are the benefits of a Context-heavy management model compared to Control?

First, distributed computing. More people using more CPU cycles, more people participating in decisions, leveraging collective intelligence. As management, your approval decision takes 30 seconds; others might spend three hours with more thorough research before judging.

Second, faster execution. No need to aggregate layer by layer, no bottleneck at a single node, no queue at the CEO's desk — more timely response.

Third, richer external information input. In Control mode, all information flows to the CEO node, who then redistributes it. The CEO becomes largely the interface between company and outside world. Compared to relying solely on the CEO to engage with markets, industries, or macroeconomics, having more colleagues and managers directly face the industry means more comprehensive information from more angles.

Fourth, engagement sparks creativity. Doing the same work, employees who understand the why as well as the what find it more meaningful than those who just follow orders. This helps unlock employee creativity.

Fifth, scalability. Context-building might take the form of internal systems, knowledge-sharing documents — these are reusable, scalable. CEO and management team time and energy have hard limits; solving problems through sheer stamina, brainpower, and endurance doesn't scale.

Of course, sometimes Control is necessary:

One, emergencies and critical projects. A major PR crisis demands rapid response. Critical projects too — if competitors are closing in, there's no time for distributed discussion and bottom-up emergence; the window closes fast. So emergencies and critical projects need Control.

Two, early-stage innovative businesses and new departments. If a department is newly established or a new executive just joined and hasn't gelled with the company yet, Control is needed. Early-stage innovation also needs more resource support and coordination, requiring CEO-level unified coordination and direction.

Three, mismatched role placement. If someone in a position is fundamentally misaligned with company values, their superior needs to intervene with Control.

Why does this problem emerge as companies develop, but not early on?

Because early on, the CEO is usually the domain expert. The business is simple, the industry landscape is simple, and the CEO can make decisions directly — it's efficient. But as the company grows, CEO attention fragments across PR, fundraising, external activities, and the organization itself becomes a major drain on managerial energy. Meanwhile, the environment grows complex, the business diversifies, and the CEO is no longer the expert, or even the most sensitive to the business. We expect CEOs to learn and grow fast, for the supercomputer to keep getting stronger with ever-broader knowledge. But human energy is finite; there are always areas where you're not as sharp as during the startup phase. Bill Gates was an excellent architect 20 years ago; 20 years later, using his vision to guide massive projects had very limited effect. Some companies don't face this because they're in stable industries with little innovation — just follow established processes. Like Lao Gan Ma chili sauce.

To summarize, we believe good organizations require:

One, exceptional people.

You need distributed processors, not just executors. Every distributed computer needs judgment capability; every one must be smart.

Two, a management model of "ample Context, minimal Control."

Everyone has their role to play, masters all relevant contextual information, and makes business decisions. With only occasional, necessary intervention.

With these two elements, you minimize transaction costs within the organization while making high-quality decisions.

Based on this philosophy, when we encounter problems, our instinct is to first ask whether Context is insufficient, rather than adding Control.

If something's off track, our first thought isn't to have someone more senior take over — it's to ask whether Context is lacking, whether we've shared industry conditions, business data, past failure cases.

As a manager, ask yourself: do you make better decisions because of superior capability, or because your Context is richer? Is there an information asymmetry at play? Look closely and you'll notice that sometimes managers even exploit information asymmetry to demonstrate their value. So first, build the foundational Context infrastructure well within the company. This isn't easy — it requires massive communication, management, and product/technical effort.

At the operational level, here are some practices we've developed:

First, reduce rules and approvals.

Departments can't issue regulations arbitrarily. When rules are unavoidable, we want them extremely simple — no multi-page documents that are impossible to enforce. Reduce approvals; ideally, eliminate them.

Second, keep organizational structure flexible, reject territorial thinking, and allow fluid reporting relationships.

Help everyone understand that reporting relationships are just one way to aggregate information — they can be adjusted anytime based on business needs.

If we have a critical project, we might need all marketing colleagues to support it. During that period, that project lead also becomes the marketing colleagues' boss.

Third, de-emphasize hierarchy and titles.

We encourage young people to speak up. I first became CEO at 26. I believe our 26-year-olds have solid practical experience and excellent education — give them good Context and they can make good decisions. To prevent formal hierarchy from suppressing frontline voices, we weaken layers. First, we ban certain forms of address — "boss," "Director So-and-so," "teacher." Once these emerge, many ideas stop surfacing. People tend to wait and hear what the "teacher" thinks before venturing their own views. We also avoid daily visible perks tied to title — who gets what computer, what desk — since this too creates hierarchy and discourages colleagues from speaking freely.

Fourth, we encourage internal information transparency.

We encourage group chats and thorough cross-department communication, not just CEO-facing communication. We also discourage one-on-one conversations, which we consider inefficient. When new hires or executives want one-on-ones with me, I often say: CC me if you like, but first send it to others, to the people you need to work with.

We keep management OKRs visible to subordinates, so everyone knows what you're working on, why, and what other departments are doing. OKR-setting isn't top-down decomposition — it's mutual alignment. Look at your manager's OKRs, other departments' OKRs, peers' OKRs. Understand the company's top priorities, this quarter's key tasks, and how your work helps others. Quarterly reviews include as many relevant people as possible, not just a small executive circle. We also hold regular CEO face-to-face sessions to answer employee questions and share company progress.

Fifth, we believe building Context fully requires good internal systems.

We have nearly 100 people on our internal tools development team, constantly experimenting. We built our own OKR system integrated with our internal IM, making it easy for everyone to view each other's OKRs.

These foundational tools first make work easier, second enable scale. New hires quickly adapt to the OKR system, quickly access internal materials and information. They also realize they have not just the right to access information, but the responsibility to support related work. These practices, in our view, treat the company as a product to be built — making internal Context more effective, making the system's distributed processing capability stronger.