Scaling doesn’t remove chaos; it changes its shape. Your job is to decide which chaos to fix, which to accept, and how to lead teams through the messy middle.
Talk transcript of Morten Lundsby Jensen – recorded on 21 Jan 2026 Scaling
Morten is a product coach working at Syndicate. He spends most of his time with product teams: different sizes, different stages, different levels of structure.
Mortne is not anti-frameworks. But he’s interested in the mechanics of when to change your org design, when to introduce new roles, when to formalize planning, or how to recognize that you’ve outgrown the way you currently work.
However, when Morten listens to teams describing their scaling challenges, and when he looks back at the situations he’s been part of himself, the hardest part is often not the theory. It’s what scaling feels like from the inside.
Scaling rarely arrives as a neat “we are now at stage 3” moment. It shows up as a persistent sense of chaos—pressure, confusion, unclear priorities, too many dependencies, too many things “that should be solved,” and not enough confidence about what to do next.
So Morten’s lens is chaos: how to work with it, how to decide what to fix, and how to lead teams through it without pretending it’s going to disappear.
Let’s hear it from Morten’s perspective…
A common way we talk about scaling goes like this:
There’s some truth in this. But it misses something important:
When teams realize they need to change how they work, the starting point is rarely “we have reached stage 3.” It’s usually:
“This feels chaotic. We probably need to do something.”
And from there, it’s easy to fall into two unhelpful extremes:
My experience is: chaos is always present, but it’s not all the same. The real work is figuring out:
Scaling is less about removing chaos and more about managing it well.
When I’m working with teams, I often come back to one question:
Which part of the chaos is manageable—and which part is not?
The mistake is treating all chaos as a problem to be eliminated.
The other mistake is accepting all chaos as “just how it is.”
The skill is knowing the difference—and acting accordingly.
One of my clearest early lessons came from a startup I worked at in San Francisco.
We built a platform for small businesses. Over about three years, the company grew from around 10 people up to around 20, and later went back down again. That up-and-down journey is useful to remember: scaling is not always a straight line.
At one point, the company hit a classic success problem:
So we did the “classic solution”: we built a self-serve onboarding experience.
We added checklists, automated emails, guides—everything you’d expect. And it worked in the sense that onboarding became more scalable.
But here’s what happened next:
We started onboarding a lot of customers who weren’t ready for the product.
The product was a force multiplier. It worked well if you were already on top of your business. But now we were efficiently onboarding customers who didn’t know what they needed, how to set things up, or how to run the underlying process the product assumed.
So we fixed one bottleneck and immediately uncovered another:
And internally the emotional response was predictable:
“Why isn’t it perfect? We solved the problem we identified.”
That moment is a good example of why scaling is not a sequence of permanent fixes. Scaling is a sequence of trade-offs. When you remove one constraint, another becomes visible.
If you follow the standard playbook, you might say:
Instead, what we actually needed in that stage was a small group of people who could navigate chaos and make things work before we knew what “the function” should look like.
So we pulled together a scrappy setup: myself, a salesperson, and someone hired as an office manager who turned out to be great at this type of work. We built an improvised customer success / account management approach on top of onboarding.
Later, we did hire someone with the “right” expertise—and they left quickly. Not because they weren’t good, but because the environment didn’t match what they expected. The chaos level was too high, and the systems weren’t mature enough for the role they wanted to do.
That mismatch matters.
Because scaling is not only about structures and roles. It’s also about who thrives in which level of ambiguity.
As teams grow, I often hear a familiar request:
Sometimes those changes are needed. But often the deeper need is different:
Teams need help deciding what matters most inside the chaos.
Because if you try to solve everything at once, you create more chaos. If you pick a big model and try to roll it out across the org, you often get performance theater and frustration.
So the approach I tend to take is more pragmatic:
It’s not elegant. It’s not neat. But it’s often effective.
I also want to share an example from a much larger organization I worked in (around 1,500 people across many locations).
This company had built a strong culture of autonomy down to the team level. That autonomy helped it grow. But over time, customer expectations changed.
Customers didn’t want a portfolio of separate tools. They wanted an integrated experience—products working together, consistent interfaces, connected workflows.
On paper, the “solution” is straightforward:
In reality, it wasn’t that simple, because autonomy was a core part of how the company worked. You couldn’t just declare a new way of operating and expect it to propagate across all teams. Even if leadership could describe the desired end state, there was no realistic way to “roll it out” cleanly.
So instead, we asked everyone to do something that sounds simple:
Write down your product strategy.
That request created about six months of chaos.
And that was the point.
It pushed conversations into the open. It forced alignment work that had been avoided. It created pressure that helped the organization move.
This is an important idea:
Not chaos for its own sake. But deliberate pressure that reveals reality and forces the organization to do the alignment work it can’t postpone anymore.
At the end of that painful period, clarity improved. People understood outcomes better. The most important cross-team integration work became visible. The organization had a more shared understanding of what “good” meant at this new scale.
But it still wasn’t “clean.”
Success looked like: still messy, but messy at a higher level.
And that can be disappointing if you’re expecting scaling to end in stability.
There’s a meme I often think about: the dog sitting in a burning room saying, “This is fine.”
It’s funny because it’s true in an uncomfortable way.
If you have leadership responsibility, you sometimes need to sit in the chaos, with some things actively on fire, and credibly say:
“This is fine.”
Not as denial. As management.
But the meme also points to the real risk: the difference between:
That distinction is one of the hardest leadership skills during scaling.
So the job becomes:
You don’t need a perfect plan. You need the ability to make decisions inside ambiguity—and to support people emotionally while they do hard work.
In the Q&A, we touched on the tension between top-down and bottom-up.
Classic agile thinking emphasizes adapting and responding. But scaling often requires deliberate direction: a decision about where you’re going, what you need to become good at, and what you’re willing to trade off to get there.
In practice, it’s both:
The chaos lens helps here, too. Leadership can’t remove all chaos, but leadership can decide which chaos is worth focusing on—and can make it safe for teams to work through the rest.
When things feel overwhelming, I fall back to a simple question:
What is the one move we can make that will cause the most useful change, without causing obvious harm?
That might be:
It’s messy. It depends on context. And it requires a leadership team that can tolerate uncertainty.
If leadership is very uncomfortable with ambiguity, this approach can be hard to execute—because it doesn’t come with the feeling of a complete blueprint.
But in many scaling situations, a full blueprint is not realistic anyway. The system changes while you’re changing it.
The part of scaling that interests me most is the psychological side.
The emotions are not side effects. They’re signals:
If you lead through scaling, your job is not to make the chaos disappear.
Your job is to:
And sometimes, your job is to sit in the mess and say:
“This is fine.”
…while also knowing exactly when it’s not.
If you want something concrete to bring back to your team, here are a few principles I’d start with:
If scaling feels chaotic, that doesn’t mean you’re failing. It often means you’re moving to a new level of complexity. The key is choosing what to do about it—and helping people through it.
Find mentors who can help you with Scaling