QIAOPANG.COM · SELECTED ESSAYS (2013–2026) · 260 ESSAYSBrowse Chronologically (2013 → 2026) ↗
QiaoPang · Programmers LifeSelected Essays · Systems, Craft & Agentic Era
Timeline ↗

The Growing Pains of a Company

The Growing Pains of a Company

Ever since I joined the ranks of entrepreneurs, I’ve found myself unconsciously putting myself in a certain seat — fretting over what I would do if I were the one at the helm. Lately, one question has been circling in my head: why is it that a company — no matter how glorious its past, no matter how strong its capacity for innovation — inevitably slides toward mediocrity, and eventually toward decline?

This seems to be a topic already covered in The Innovator’s Dilemma. That book explains how disruptive technologies displace incumbent ones, and how the very forces that make a well-managed company strong prevent it from developing disruptive technologies itself — forces that cause the company to hand the low and mid-range markets to challengers, retreat step by step into the high end, and finally perish. Its case studies are both riveting and thought-provoking. If you haven’t read The Innovator’s Dilemma, pick it up on your commute; it beats playing mobile games, scrolling Weibo, or reading my essays.

What I want to talk about, though, is another cause — one that has to do with people: talent density.

In a company’s earliest days, its talent density is at its peak. The team consists of nothing but the people directly tied to product (R&D) and business (sales). If talent density can be expressed as:

Dt = (employees who directly create enterprise value / total employees) x (working hours spent directly creating value / total working hours) x average employee capability

Then at this stage Dt approaches 1 asymptotically.

Later, as the company grows, headcount rises and the business becomes more complex, and more roles that don’t directly create value get introduced: front-line managers, HR, secretaries, finance, IT, etc. Dt begins to oscillate downward, drifting away from 1. More people, more roles, and a more complex business mean processes that must be continually refined to constrain and guide the work — which inevitably brings higher management overhead, further eroding the hours spent directly creating value. Then the Matthew effect gradually sets in: the drop in effective working hours calls for more people to make up for it; more people bring an even more complex human structure, more granular business processes, higher management overhead, and more meetings, documents, and paperwork — and in the end, everyone’s efficiency keeps sliding.

Google once tried to rebel: it fired all its managers, which quickly produced disastrous consequences, so it went back to a conventional organizational structure.

Human potential peaks when people are given authority and responsibility directly. When a project must be approved level by level, when spending even a little money runs into a thicket of restrictions, when even a few lines of code must be reviewed by multiple teams, everyone’s potential is drained away. Managers start to seek stability and to maximize “going by the book,” so that the odds of making a mistake shrink; each employee just quietly does the work in front of them and buries fresh ideas deep inside.

So the people unwilling to settle for mediocrity begin to leave, while those who stay — hemmed in on every side — see their capabilities drift down toward the company average. By the law of talent flow, absent some extraordinary incentive, a company’s average employee capability determines the capability of the people it can hire. And so, as talent continually flows out and in, the average capability of the workforce keeps getting dragged down.

When Google began to boom, plenty of Microsoft employees jumped ship to join it; when Facebook was opening up new territory in social, plenty of Google employees were lured away. Excellent people always want to flow toward companies with high talent density (as I’ve defined it), because that’s where there’s room to stretch out — where working hours are mostly spent creating value.

I don’t know how to break out of this trap. Without practice, one has no right to speak. But if I’m going to armchair-strategize, these are the measures I’d want to try:

Keep salaries permanently at the top of the industry. Better to hire fewer people, and to pay the ones you hire well. This is exactly the point of the story Guo Kui told King Zhao of Yan — “a thousand pieces of gold for a horse’s bones.” Give front-line teams ample authority and responsibility. Decision-making and execution power for a product (or a feature) should be pushed down to the front-line team, not held by middle and senior managers who insist on personally leading the charge. Front-line employees should have the courage and sense of ownership to act and to own the outcome — to carry their own heads back if they lose. Why does the sales team always produce heroes? Because its people have authority, responsibility, and accountability. Cut processes to the bone, and reduce the number of layers in the org chart. Many newer companies are experimenting with this — Twitter, GitHub, Netflix (and plenty of little-known startups). Whether it works, I can’t say, but it looks like the right road. Netflix reportedly has abolished even the expense-report, travel, and leave-request processes; the company trusts employees to make the judgment and choice that best serve it. Instill it through culture, so that the previous three points take root at the foundation.

MORE IN Leadership & Career

Further Reading in This Column

View all essays in “Leadership & Career” →

The Programmer's Meltdown

After enduring the 'unsafe shitstorm,' actix-web's maintainer pulled the top-ranked Rust framework and walked away from open source—a story of maintainer burnout and the hidden cost of demanding that volunteers reshape their work for everyone else.

Book Next Chronicles (2013–2020)2,451 chars · 5 min read

Nana the Intern

When it comes to interns, beyond learning ability, I ask for one thing: a long enough runway. By "long enough" I mean at least two or three months — anything shorter and they leave before contributing anything of value, clutching a glowing evaluation form. Nana's story is an exception worth studying.

程序人生 (2015–2019)4,528 chars · 10 min read

ArcBlock at One Year

One year since trading the Bay Area for Washington State: a reflection on the winding road that built ArcBlock — its Forge framework, its bet on application chains, and the choices that led here.

Book Next Chronicles (2013–2020)6,593 chars · 15 min read