The ego problem in scaling companies

The most expensive thing in a scaling company might be its ego

There’s a particular kind of disorientation that comes from joining a scaling organisation after spending years inside larger ones. Things you’ve come to think of as fairly basic suddenly become surprisingly difficult conversations: decision rights, quality standards, design systems, research infrastructure, team shape, clear ownership, and the difference between shipping something and building something that can scale.

It can feel like going backwards.

That reaction itself is worth examining, because experience comes with ego. It’s easy to arrive somewhere new and think, I’ve seen this before. I know how this works.

Sometimes you do. Sometimes you absolutely don’t.

The useful part of experience isn’t assuming you have the answer. It’s recognising the pattern early enough to ask a better question.

When urgency is really accumulated debt

One of my favourite quotes comes, somewhat improbably, from Stewie in Family Guy:

“Ma’am, don’t make your lack of planning my emergency.”

I think about it far more often at work than I probably should, because a surprising amount of organisational urgency isn’t really urgency. It’s debt coming due.

A decision wasn’t made six months ago. Ownership was left deliberately vague. A team was asked to stretch instead of being properly staffed. A system wasn’t built because it felt too early. Quality was traded for speed, repeatedly. A temporary workaround quietly became the operating model.

Eventually those decisions compound until something becomes urgent. Now everyone needs to sprint. And because the visible problem appeared today, it gets treated as though it was created today.

Experienced people often have a different reaction because they’ve seen the sequence before. The emergency may be new. The conditions that created it usually aren’t.

Experience changes the shape of the problem

This is probably the biggest shift I’ve noticed as I’ve become more experienced. Fewer organisational problems feel entirely novel.

That doesn’t mean they’re easy. It means you begin recognising categories of problems earlier.

“We need Design to move faster” might actually mean the teams are under-resourced, the problem isn’t defined clearly enough, and decision-making is happening too late.

“We need better collaboration” might actually be a decision-rights problem.

“We need more consistency” might be the predictable result of multiple teams solving the same problem independently without shared patterns or infrastructure.

“We need everyone to take more ownership” might mean nobody has actually been given the authority required to own anything.

Those distinctions matter. Someone encountering the problem for the first time may spend months diagnosing it. Someone who has seen it three times before might recognise it in a week.

That’s one of the real values of experience. It compresses learning.

Not because experienced people are inherently smarter, but because the problem is no longer new to them.

Experience has an ego problem too

There’s an obvious danger here, though. “I’ve seen this before” can very quickly become, “Therefore, I’m right.”

That’s not experience. That’s arrogance wearing experience as evidence.

You can’t simply import the operating model of a 20,000-person organisation into a 500-person company. You shouldn’t recreate Atlassian, Adobe, Google, Amazon, or anywhere else inside the next place you work.

Practices exist in context.

The interesting question isn’t, “How did my previous company do this?”

It’s, “What did they eventually learn that caused them to work that way?”

That distinction is important. You don’t necessarily want the process. You want the lesson that created the process. Maybe you can achieve the same outcome with one tenth of the machinery.

That should be the advantage of bringing experience into a smaller organisation.

Delusions of uniqueness

The opposite ego problem is just as dangerous.

One of my favourite ideas from Scaling Up Excellence is “delusions of uniqueness.” It describes the belief that the normal lessons somehow don’t apply to us.

Our company is different. Our culture is different. Our founders are different. Our customers are different. Our speed is our advantage. Process would slow us down. Quality can come later. We don’t need that kind of structure yet.

And sometimes the organisation really is different. But being distinctive doesn’t exempt you from the physics of scale.

More people create more coordination. More products create more inconsistency. More teams create more dependencies. More customers create more edge cases. More markets create more complexity. More revenue increases the cost of poor experiences.

You can be building something genuinely unique and still run into remarkably ordinary scaling problems.

That isn’t failure. It’s scale.

Why craft becomes vulnerable

Craft is particularly vulnerable to this because it can be difficult to value in organisations that grew quickly without much formal design infrastructure. And there’s a reason for that.

Early-stage companies can compensate for an enormous amount. The founders carry huge amounts of product context in their heads. Teams are small enough to resolve ambiguity through conversation. People sit close to the customer. Individuals bridge gaps through sheer effort. Customers may tolerate rough edges because the underlying proposition is valuable enough.

Speed matters enormously, and the organisation learns an understandable lesson: this is how we win.

The problem is that what got you through one stage of growth can become a liability in the next.

Heroics don’t scale particularly well. Neither does implicit knowledge. Neither does everyone making slightly different versions of the same decision.

Eventually the rough edges join together. Now you have duplicated solutions, fragmented journeys, inconsistent interaction patterns, confused ownership, growing support costs and experience debt.

And often the instinct is still: go faster.

That’s where craft gets misunderstood.

Systems, standards and deliberate experience design can look like friction when viewed through the lens of immediate delivery. But at scale, those things increasingly become the infrastructure that allows you to move quickly.

A design system isn’t valuable because mature companies have one. It’s valuable because twenty teams independently solving buttons, forms, workflows and interaction patterns is a spectacular waste of time.

Research isn’t valuable because Design likes research. It’s valuable because confidently building the wrong thing is an expensive way to move quickly.

Quality isn’t valuable because designers have unusually refined taste. It’s valuable because customers experience your organisational decisions whether you intended them to or not.

When speed becomes the answer to everything

Founders have another difficult challenge. As companies grow, they’re surrounded by increasingly specialised advice.

Investors think about growth. Sales thinks about revenue. Engineering thinks about reliability and throughput. Product thinks about roadmap and outcomes. Finance thinks about efficiency. Design thinks about the coherence and quality of the experience.

All of these perspectives matter. The problem comes when one becomes the answer to everything, particularly speed.

Move faster. Ship more. Compress the timeline. Add another team. Find the shortcut.

There are plenty of moments where this is exactly the right advice. But building a fast-growing company and building a coherent product experience are overlapping disciplines, not identical ones.

Eventually relentless optimisation for speed starts transferring cost elsewhere. Into the product. Into the teams. Into support. Into rework. Into customers having to understand things that the organisation never properly resolved itself.

And experienced practitioners can become inconvenient at this point. Not because they don’t want to move quickly, but because they can see the bill arriving.

What experience should actually buy you

The value of experienced hires shouldn’t be another layer of process. It should be leverage.

That leverage shows up first in pattern recognition: seeing a scaling problem before it becomes a crisis. It shows up in compression: reducing the amount of time the organisation needs to learn something others have already learned. And it shows up in prevention: recognising which seemingly harmless shortcuts become extremely expensive when multiplied across teams, products and customers.

Experience should reduce the number of organisational lessons you need to learn the hard way. That’s the return.

Otherwise you’re paying for someone’s history without actually using it.

Eventually, the question changes

Earlier in a career, a lot of energy goes into learning how. How do I build the thing? How do I run the research? How do I create the system? How do I structure the team? How do I influence the strategy? How do I raise the quality bar?

Over time, you accumulate those lessons. You make mistakes. You see things work. You see things fail spectacularly. You develop judgement about which problems require sophisticated solutions and which require incredibly boring ones.

Eventually, the constraint changes.

The question isn’t always: Do you know how to do this?

It becomes: Are you actually enabled to do it?

Do you have decision rights? Do you have the resources? Are you involved early enough to shape the decision rather than decorate it afterwards? Can you establish a quality bar? Can you change the system producing the problem? Will the organisation support the uncomfortable implications of the expertise it hired?

Because there is another form of organisational ego hiding here.

It’s hiring experienced people and then discounting their experience when it conflicts with the way you already wanted to operate.

Humility has to work both ways

There has to be humility on both sides.

The experienced person has to accept: My experience doesn’t automatically make me right.

And the organisation has to accept: Our unfamiliarity with a practice doesn’t make it unnecessary.

That is probably where the healthiest scaling happens.

Scaling companies often hire experience because they want the benefit of someone who has been there before. Someone who recognises what tends to break next. Someone who can help them skip a few expensive lessons.

The mistake is hiring that experience and then asking them to behave as though they haven’t.

The ego problem in scaling companies was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.