Skip to content

Fast Growth Doesn't Prove Your Org Design Was Right

October 10, 2026

og-cover

The Short Answer

This piece answers one concrete question: before you copy a fast-growing company's org chart — or before you put your own organization in the dock for a slow quarter — how do you decide whether a business result should be booked to the organization at all.

The judgment: a fast-growing company proves nothing about whether the org design was done right — the industry and the product may be doing the carrying. A slow-growing company proves nothing about organizational failure either — demand may simply have left. Growth is not evidence of good organizational design. Growth is the free pass organizational problems use to skip the inspection.

One boundary before we start: this piece splits the ledger; it does not acquit the organization. The problems growth papers over are still accruing interest, and the bill still comes due. It is not an "organizations don't matter" brief either. Every evidence grade and every failure corner gets unpacked in "Where the Method Breaks Down" at the end.

I Finished the Season. Then I Audited It

After writing a full season of "AI organization field reports," I did one thing I should have done before writing a word: I lined up the twelve case companies and went back through them, one by one.

What I found chilled me a little. Coda, Gojek, Gong, the company that cut roles, the company that bet everything on experiments — the protagonists I chose for this season were almost all growing fast. I spent an entire season digging organizational practice out from under growth's halo, and I never once stopped to ask: were these practices actually validated — or merely stamped by growth?

This piece is not a thirteenth take. It is me reneging on how I read the whole season. Growth is not evidence that an organization was built right. Growth is the free pass organizational problems use to skip the inspection.

The most expensive part of a free pass is the procedure it waives: producing evidence. While a company is growing, its structure automatically looks sound, and its practices automatically get called "best practices." Outsiders arrive with magnifying glasses to copy them; insiders put them into decks and carry them upward. And at no point, anywhere, is anyone required to prove that the practices themselves work. The stamp came from growth, not from evidence.

But the knife has to cut both ways: a slow-growing company proves nothing about organizational decline either. Maybe demand simply left — and a perfectly functional organization temporarily looks like a loser. The free pass is a one-way exemption; the reverse guilt-by-association needs no evidence either.

First, a Witness

A retraction needs evidence. In this season's interviews, someone happened to say it out loud.

Tamar Yehoshua, President of Product and Technology at Glean — in the show's opening introduction, one of the most successful enterprise AI companies of the moment. Before that she ran product at Slack; before that, she led teams at Google and Amazon. The host hands her a counterintuitive thesis: a company does not need to be managed well to win.

Her answer has two layers. The first is her position: she likes well-run companies, and she wants to run her own team that way — that is not a pleasantry, it is the premise she speaks from. The second layer is what she has seen: the organizations she has personally watched do not follow that wish.

Two scenes, on the table:

The sceneWhat the organization looks likeThe result on the table
Scene oneExecutives churning constantly, employees getting yelled at and fired, everyone she talked to unhappyNumbers scarily good, growth running wild
Scene twoExcellent CEO, machine fully oiled, every executive hire sharpFlatlined — seats filled, process humming, and no new card ever hits the table

Both scenes are full of actual people. In the first, the executives making decisions cannot keep their seats, the people doing the work absorb it first, and the numbers on the table climb anyway. In the second, the seats are filled and the process hums, and the table produces nothing new.

Her exact words: "they're not correlated to the company being successful."

Watch how she says it — it matters more than the conclusion. She names neither company, and in the same breath she explicitly carves out the employer she currently works for. Everything offered is personal anecdote, not research. And she never says chaos buys wins. Her claim is not that chaos works. Her claim is that these two ledgers do not move together.

Those qualifiers do not depreciate the testimony; they mark its usable range. She only spoke as far as she spoke, so we only get to use her that far. Someone who pre-emptively excludes her own employer is not trying to sell anecdote as law — and when we quote her, we should not upgrade her license either.

Why the Tailwind Keeps Paying for Bad Books

She did offer one explanation for growth-stage chaos, and it runs against intuition: chaos does not cause growth — growth mass-produces chaos. Once you have hit real demand, you grow fast or growth stops: infrastructure breaks, communication frays, at any given moment half the company has been there less than six months, and try "getting the organization in order" when you cannot yet put faces to names. She appended one extreme sample: Myspace — killed by a slow product.

So do not rush to harvest a growth company's chaos as an organizational asset. Customers are queuing; the demand-side window forces the company to leave its internal books on hold — the organization's debts go on deferred payment. Growth does not pay the bill for bad books. It only extends the payment terms.

Deferred is not forgiven. The people inside pay it down daily: onboarding work that never makes it into anyone's hours, processes rewritten right after you finally memorized them — the front line absorbs all of it first. The free pass exempts a company from outside scrutiny; it cannot exempt anyone from what the place feels like from inside. Nobody books this to the ledger, and by the time it shows up on the books it has usually changed its name — to attrition, to execution drift.

When does the bill come due? Somewhere in the interview this line got put on the table: past five to ten thousand people, once the market is won, you bring in professional managers and get the organization under control — a staged account, and she took it on board. At that point the days of running a tab end, and it is the organization's turn to pay.

She drew one more line: not every kind of chaos rides on the free pass. Strategy that changes weekly, projects torn down and restarted in new costumes, people redirected before they have finished anything — by her standard, that chaos is not okay. And I would put it harder: that chaos is not the price of growth. It is the disease itself.

The Reverse Injustice Is Also in Session

The other edge of the knife is the one people like me see most. I spent eighteen years in HR. In the years when the market turned, I knew the first sentence of every retrospective by heart: "the organization can't keep up." Slow processes, too many layers, long decision chains — every one an indictment. Then the structure gets dismantled, collaboration roles get merged, the owner gets replaced. And the very same process, in the good years, had another name: "steady."

Two missed quarters, and the organization enters the dock before anyone asks why. By the time the demand tide returns — if it returns — the organization has been through three restructurings, and the people who were best at collaboration left rounds ago. The blade lands on the people carrying the collaboration, while the real cause may never have entered the room.

And the trial has an asymmetry. In good years, when "steady" gets praised, nobody is asked to prove the collaboration mechanism actually contributed anything. In bad years, when "can't keep up" gets punished, nobody is asked to prove the organization was actually the main cause. Praise and punishment use the same lazy ruler — read the result, attribute directly. When the burden of proof is unguarded at both ends, both ends book the entry wrong.

This season I nearly committed the same offense myself. One of my twelve companies was the exception that did not arrive on growth's coattails: Intercom — the founder said it himself, net new revenue fell five straight quarters, each one worse than the last. Today the same company gets told as the "bet everything on AI and turned it around" story. In the down years, nobody praised its organization. After the turnaround, nobody asked whether the organization had changed at all.

Sentence organizations by results, and the winners collect a prize the market earned on their behalf, while the losers serve time for a crime the market committed.

None of this is a new discovery. Management scholarship devoted an entire book to the trick — The Halo Effect, a dissection of precisely the loop where "the results are good, so assume everything is good." I am not reselling an old concept; I am pressing it into this season's new crime scene: AI organization case studies.

Three Questions and a Retraction Clause

So how should the verdict get written? Here is the procedure I have started using on myself: split the ledger first, notarize second.

Before you attribute any business result to an organization — whether you are about to copy a growth star's org chart or about to make an organization pay for a miss — split three books first:

The three questionsWhich money they ask aboutWhere the answer points
Question one: is industry demand growing?The demand-side marketGrowing — that is the tailwind's money
Question two: does the product itself hold up?Product strengthIt holds — that is the product's money
Question three: would swapping out this collaboration mechanism change the result?The organization itselfIt would — that is the organization's money

After the three questions, notarize the counter-evidence: write down "what evidence, if it appears, makes me withdraw this organizational explanation." For example:

"Industry-wide demand falls thirty percent while our collaboration keeps running normally — then the organization was not the main variable."

Do not notarize in your head. Put it on page one of the retrospective document — a notarization kept in your head is one you are free to disown later.

Notice what the three questions move: not the organization's credit or its guilt — its burden of proof. For the organization to collect credit, it must first pass question three: show that swapping this collaboration mechanism would actually change the result. For the organization to take the blame, it must first pass questions one and two: show that the market and the product were not already covering for it. Get the burden of proof into the right place, and a verdict becomes worth writing down.

One rule: if the three questions cannot be answered, do not issue an organizational verdict yet. Do not rush to copy, do not rush to punish.

I applied the procedure to myself first. I went back through the twelve pieces and re-asked the questions; question one comes back "growing" on nearly every page. That does not overturn the field observations themselves — who picked up the work, who made the call, all of that is real. What it overturns is my reading of them: they should be treated as practices pending validation, not proven best practices. This season taught how to read an organization's ledger in fine detail. This piece adds the correction: do not book someone else's business result into the organization's account.

Where the Method Breaks Down

First, the evidence grade. Yehoshua's two scenarios are personal anecdotes: no named companies, no sourced numbers, no causal tests. The two-way claim — free pass in good times, wrongful conviction in bad — is interview opinion, not research findings. If you use it to prove "growth and organization are unrelated," you have used it beyond its license.

Splitting the ledger does not exempt the organization from responsibility. Growth masking a problem is not the problem disappearing; the debt is still accruing interest. When the topic wrapped, it was the host who took the handoff and landed it: chaos is not success, and it is no excuse to let an organization rot — you still owe it a working organization, and a room where the people doing the work are glad and motivated. The book-side standard says the same: before copying another company's org design, ask whether its conditions and its support are comparable; where the evidence runs thin, record "unknown"; and if waiting time went down while net outcomes got worse, that is still failure. This piece is a ledger-splitting method. It is not an "organizations don't matter" brief.

The three questions have blind corners. The organization's money never appears as its own line item in a financial statement; the questions can straighten your reading, but they cannot compute "the organization contributed X percent." The notarization stops gut calls; it cannot stop late evidence — a thirty-percent industry decline usually takes a business cycle or two to arrive, and by the time it lands, the org chart has already been copied and the people have already left. And in some businesses, with identical demand and identical products, the speed of collaboration decides survival outright — there, question three outweighs the first two combined, and the ledger split grants no exemptions.

If You Can't Write the Retraction Clause, Don't Sign

So the next time you are about to copy someone's org chart, or about to name who takes the fall — do the one thing first: write down the conditions under which you would withdraw.

If you cannot write them, what you are about to issue is not a verdict. It is a stance.

An organizational verdict without written retraction conditions — do not sign it yet.


The next reads pick themselves: “Your MVP Failed. It May Not Have Refuted Your Idea.” works the other half of the same mis-booking — when the numbers turn ugly, what got falsified may not be your idea at all. And “Does Managing More Mean Contributing More?” takes apart how credit gets booked wrong — the scope was the company's hand; the result was your play. Run the three questions first, and an organizational verdict has earned the right to be written down.

I'm Uncle J. I run a one-person AI organization, and I hold it to this piece's rule at a scale of one: a good quarter is not proof the setup works. Before I credit my own system, I run the three questions and keep the retraction clause in writing. When the output looks great, I don't applaud the machine — I ask which account the result was booked to.

AI Organization OS Diagnostic

If this essay describes your organization, run the diagnostic next.

Use 26 questions to locate the broken layer: roles, workflows, knowledge, accountability, or governance.

Open diagnostic

Want to turn this into an operating system? Send Uncle J the context →

J叔

Subscribe to Uncle J's Insider

Notes on AI organization, AI HR, agentic engineering, and content systems when they are worth sending.