The Day Everything Got Harder

Maya opens the meeting with one sentence.

"We need to move faster."

For the next forty minutes, Lars talks about the monolith. Priya talks about ownership gaps. Kai takes notes and says less than usual. Maya listens to all of it. At the end, nobody has answered anyone else, but the meeting ends with a plan, and the plan is to meet again next week.

If you've been in a room like this, what you remember isn't the specific agenda items. It's the texture of the conversation. The careful non-disagreement. The sense that everyone is talking around something rather than about it. The way the meeting concludes and nothing has shifted.

Velox is three years old, sixty people, grown from eight. It is slower now than it was at twenty. The leadership team knows something is wrong. What they don't have yet is a way to name what kind of problem they're in.

That's where this course starts.

Why growth changes the system, not just the headcount

There's a common story about what happens when a company grows. A small, fast company adds people, the people add process, the process adds drag, and eventually a slow large company exists where a nimble small one used to be. The implication is that the problem is the process, and the solution is to remove it.

This story is wrong in the specific way that matters.

At eight people, Velox ran on informal coordination. Not as a policy choice, but as a natural property of its size. When the entire company shares a workspace with a handful of people, information travels without effort. Decisions happen in conversations that weren't scheduled as decisions. Problems surface before they become blockers because the communication network is dense enough that nothing stays invisible for long.

That informal system is remarkably effective. It is also not scalable.

The coordination patterns that carried Velox at eight have a natural capacity limit. As the organization grows beyond that limit, those patterns don't degrade gracefully. They stop working. Not because the people changed. Not because the process got in the way. Because the informal structure that made things work at small scale cannot accommodate the communication load of sixty people working across multiple teams, product surfaces, and shifting priorities.

Growth doesn't make an organization bigger. It changes the system. What worked at eight people breaks at sixty not because people got worse, but because the informal coordination patterns simply cannot scale. Maya's instinct to mandate faster execution is correct about the symptom and wrong about the cause.

Heidi Helfand spent years embedded in high-growth software companies, including Expertcity, which grew from a handful of people to over 700 while she was there, and studied team change patterns across the industry. Her research produced a finding that runs against most team design advice: team change in high-growth organizations isn't a sign that something went wrong. It's the structural norm. Her "Grow and Split" pattern describes what happens when a team grows beyond the coordination capacity of its current structure. Not failure, but an invitation to redesign. The right response is to divide into smaller, more focused units, not to hire more people into a structure that has reached its ceiling.

Velox hasn't done this yet. What it has done is add thirty-two people to a system designed for eight, and then wondered why everything got harder.

The four views in the room

Go back to that meeting. Not to find out who was right.

Lars says: "If we break the monolith, teams can ship independently." He's looking at technical coupling, the way changes in one part of the codebase create unpredictable effects in others. He's not wrong.

Priya says: "The problem is that nobody knows who owns what." She's looking at accountability structure, the way unclear ownership forces every non-trivial decision to escalate upward, and why her inbox is full of things that shouldn't be there. She's not wrong either.

Kai writes something in his notebook. He's thinking about how teams hand things off to each other, and noticing that six months of structural work hasn't made those interactions cleaner. He's not saying this out loud yet. But the observation is there, in the notebook.

Maya says nothing for a long moment. Then: "But whose problem is this, actually?" She's looking at business velocity, the way every release has gotten harder, and what that means for the company's position. She's not wrong.

Four people, simultaneously correct, talking past each other. Each sees a real element of the problem. None sees the whole system.

This isn't a communication failure or a personality conflict. When an organization reaches this kind of complexity, the same underlying problem presents differently depending on where you're standing. Lars sees it through a technical lens. Priya through an operational one. Kai through a structural one. Maya through a strategic one.

These four views will be a navigation device throughout this course. Every concept we examine, every framework we test, every design decision we question, we'll run through all four lenses. The system that needs redesigning has elements that are only visible from each position.

Why doing everything right still isn't enough

Maya didn't ignore the problem. She saw it early. She called the meeting, mandated her team to find answers, gave them the authority and time to do it. By any normal measure, she did everything right.

And nothing moved.

The default story about organizational dysfunction assumes someone failed to act. That story doesn't apply here. Velox's leadership team is experienced, motivated, and paying attention. The friction isn't incompetence. It's structural.

Well-run organizations can stay exactly as stuck as badly-run ones when the problem is in the system rather than in the people operating it. Velox's response, more meetings, a mandate for speed, a framework rollout, addressed the feeling of the problem. It didn't touch the structure that produces it.

Six months from now, if Velox makes no structural changes, the same meeting will happen again. Different agenda items, same texture. New Slack channels where information still doesn't flow. Different symptom surfaces. The same underlying system, unchanged.

Further Reading

Exercise