The Snake Eating Its Tail: Growth at All Costs, and What Builders Can Do

The ouroboros is an old symbol: a snake swallowing its own tail. It usually stands for renewal, a cycle that feeds itself. I've started seeing it as something darker. It's a system that has run out of things to eat and turned on itself.

That's how a lot of the tech industry feels to me right now. Not because capitalism is evil, and not because growth is bad. Growth has paid for most of what I've built and most of the teams I've led. The problem is growth as a mandate: the expectation that a company must get bigger every quarter, forever, whether or not getting bigger makes it better.

This isn't a rant. I'm a founder, and I want my companies to grow. It's an attempt to describe how the mandate shows up in the everyday work of building software, and what the people doing that work can actually do about it.

When the result becomes the goal#

Healthy growth is a result. You make something people value, they tell other people, and more people pay for it. The product gets better because the company can afford to invest in it.

The trouble starts when growth stops being the result and becomes the goal. There's an old idea, usually credited to the economist Charles Goodhart, that when a measure becomes a target, it stops being a good measure. Growth targets are a perfect example. Once the number is the point, there are always ways to move it that make the underlying thing worse.

At first, you grow by making the product better. Then you grow by reaching more people. Eventually you run out of easy new people, but the target still has to go up. So the company starts growing by taking more from the people it already has: more of their money, their attention, their data, their patience. That's the snake reaching its own tail.

How it shows up in product#

You don't need a finance degree to spot it. It shows up in the product itself:

• Dark patterns creep in. Cancellation flows get longer. Defaults quietly favor the company. The "skip" button gets smaller every redesign.
• Prices rise faster than value. Features you already had move into a higher tier. A product gets more expensive without getting better.
• Engagement replaces usefulness. Teams are measured on time spent, not on whether people got what they came for. A product that solves your problem quickly looks like a failure on that dashboard.
• Ads and upsells fill every surface. Space that used to help the user is now inventory.
• Quality debt piles up. Reliability work, accessibility and support lose every prioritization fight to whatever moves the number this quarter.

None of these is a single bad decision. Each is a small, defensible choice made under pressure. Together they slowly change what the product is.

How it shows up inside teams#

The same pressure lands on the people who build the product.

• Roadmaps become promises to investors, not to customers. Work gets scoped to fit a reporting cycle instead of a real problem.
• Teams are hired for a growth curve, then cut when the curve flattens. People are treated as a cost to tune, and the institutional knowledge leaves with them.
• Everything is urgent. When every quarter has to beat the last, there's no time to pay down debt, mentor anyone, or think.
• Metrics get gamed, often without anyone meaning to. When a team's survival depends on a number, the team learns to move the number.
• The people who care most burn out first. They're the ones holding the product together while the incentives pull it apart.

I've been on several sides of this: building products, leading engineering at large organizations, running product at a startup that was acquired, and now founding companies myself. The pressure is real at every level. Pretending it isn't helps nobody.

Why it's self-defeating#

The cruel part of the ouroboros is that it doesn't even work on its own terms. A company that consumes its customers' trust eventually loses customers. A company that burns out its best engineers eventually can't ship. A product that's been tuned for engagement over usefulness eventually gets replaced by one that just works.

The same is true at the scale of an industry. When every company chases the same users with the same tactics, the whole market gets more expensive to acquire, more annoying to use and harder to trust. Everyone is running faster to stay in place. Growth at all costs usually doesn't fail with a crash. It fails slowly: a product people still use but no longer love, and a team that still ships but no longer believes in what it's shipping.

What builders can actually do#

Most of us can't rewrite how capital markets work. But builders have more influence over day-to-day decisions than we usually use. Here's what I try to do.

Measure value, not just volume. For every growth metric on a dashboard, put a value metric next to it. Did the user finish what they came to do? How long did it take? Did they come back because they wanted to or because we made leaving hard? If you can only influence one dashboard, make it this one.

Name the dark pattern in the review. When a design or spec makes something harder for the user in order to move a number, say so plainly in the review. Calm, specific and on the record. You'll be surprised how often nobody else wanted it either.

Protect quality work explicitly. Reliability, accessibility, security and debt work shouldn't have to compete with features every sprint. Give them a fixed share of capacity and defend it.

Build things that run themselves. A lot of the human cost of growth pressure comes from fragile systems that need heroes. When the system runs itself, with automated gates, clear ownership and good tooling, the team doesn't have to absorb every spike. That's a big part of why I build agentic infrastructure: so a small team can do serious work without anyone carrying all of it alone.

Size the company to the problem. As a founder, the most radical thing I can do is decide what "enough" looks like. A company can be profitable, useful and stable without trying to be enormous. That's a real choice, and it's available more often than people think.

Choose customers who want to be served, not extracted. Pricing, positioning and who you sell to all decide which incentives you'll face later. Products priced on the value they create age better than products priced on how stuck the customer is.

Be honest with your team. If the pressure is coming, say so and explain why. People can handle hard truths. What breaks trust is being surprised by them.

Questions I bring to planning#

When a roadmap or a target lands on my desk, these are the questions I ask before agreeing to it:

1. If we hit this number, is the customer better off? If the honest answer is "not necessarily," the number needs a partner metric.
2. What are we taking, and from whom? Every growth plan pulls from somewhere: new users, existing users' wallets, team hours, or quality. Say which one.
3. What would we stop doing to make room? A plan that only adds work is a plan to burn people out.
4. What happens if we miss? If missing means layoffs or a product compromise, that risk should be discussed now, not discovered later.
5. Would I be comfortable explaining this to a customer? If not, we probably shouldn't build it.

None of these stops a company from growing. They just keep growth attached to something real.

What I'm trying to build instead#

I don't have this figured out. But I know what I want my companies to feel like from the inside: calm, deliberate and clear about why the work matters. Growth should be a sign that we made something worth having, not the reason we exist.

In practice that means:

• writing down what success means for customers before writing down revenue targets
• keeping teams small enough that everyone knows why their work matters
• automating the toil, so people spend their time on judgment and care
• saying no to revenue that would make the product worse

The takeaway#

Growth isn't the enemy. Growth as an unquestioned mandate is. It slowly turns companies into systems that eat the things that made them worth building.

Builders sit closest to where that happens: in the spec, the design review, the sprint plan and the architecture. We can't fix the whole system, but we can refuse to feed the snake one small decision at a time. Over a career, those small decisions add up to the kind of company, and the kind of work, you'd actually want to be part of.