The Company That Grew Faster Than Its Structure

A release sits finished in staging for three weeks. Not because anyone is slow or careless. Because Team A is waiting on a sign-off from Team B. Team B is waiting on a database change owned, loosely, by Team C. Team C is waiting on an architectural call that Lars hasn't made yet because nobody told him it was blocking. The Product team doesn't know the release exists. Maya finds out from a customer asking why the feature isn't live yet.

This is the moment she calls the meeting. And if you've been in a growing software organization, you've probably seen some version of this room. The names were different. The details were different. The feeling was the same.

Velox, three years in

Velox is a B2B SaaS for project management. Three years old. Started by Maya Rojas with two engineers and a conviction that the way software teams tracked their work was fundamentally broken. They were right. Within three years, Velox grew from eight people to sixty, from a handful of paying customers to a product that teams across more than a dozen countries use daily.

This is a success story. That's worth sitting with for a moment, because what comes next is not a story about a startup that made the wrong strategic bets. It's a story about what happens to a right decision, to a real product, to a capable team, when the organization that built it grows faster than the coordination system holding it together.

At Velox right now, four people are trying to figure out what's wrong. You'll spend this course with them.

Maya Rojas, CEO and founder. Velox is her company in the most personal sense. Five years of work, hundreds of customer conversations, a hundred hiring decisions. She's the first person who sensed something was wrong, and she framed it, immediately, as a business velocity problem: "We need to move faster." That framing is not wrong. It's also not complete.

Lars Hoffmann, CTO. Lars sees architecture. The Velox codebase is a Rails monolith that grew organically with the company, a structure that made sense at eight and is showing its age at sixty. Lars is not wrong that the architecture needs attention. What he's doing is treating the architectural problem as the root cause of the organizational problem, when they're actually two symptoms of the same thing.

Priya Sharma, Head of Engineering. Priya manages five team leads and watches, every day, as ownership blurs and decisions that don't belong on her desk land there anyway. She believes it's a people and process problem. She's also not wrong. She's describing one face of a two-faced system.

Kai Bergmann, external Agile Coach. Kai has been at Velox for six months. He arrived with energy, frameworks, and a plan. He initiated some structural changes, got a few processes moving. The changes landed. The clarity everyone expected didn't follow. He hasn't said this out loud yet, but he's starting to wonder whether he's been applying the right tools to the wrong problem.

Four lenses pointed at the same organization, seeing four different things. That's not a perception failure. It's a structural one. Understanding it requires going back to where it worked.

What eight people could do without trying

Think about the Velox of three years ago. Eight people. Maya, two engineers, a designer, and a few people handling customer success and sales. Not a lot of formal process. Not a lot of need for it.

When someone hit a blocker, they turned in their chair. When something changed, it spread through the room before anyone had to document it. When a decision was needed, it happened in the hallway before it needed a meeting slot. The product, the engineering, and the customer feedback all lived in the same room, handled by people who knew what each other were doing, not because there was a system for that, but because they shared the same physical and informational space.

This is not a startup cliché. It's a structural property of small, co-located groups. In close proximity, with high mutual visibility, people don't need explicit coordination mechanisms because the environment itself is a coordination mechanism. Problems surface before they become blockers. Context travels faster than decisions need to be made. Ownership is clear because there aren't enough people for it to be ambiguous.

This system worked. And it had a capacity ceiling.

The informal network that carries eight people has a capacity ceiling. At sixty, the release that nobody told anyone about is not an exception - it is the expected output of the structure.

The system that hit its ceiling

At sixty people, Velox has five teams. Teams that don't share a physical space, don't have the mutual visibility the original eight had, and haven't built the explicit coordination systems that would replace what proximity used to provide automatically.

The release that sat in staging for three weeks was not a failure of any individual. It was the expected output of a coordination system that had not grown alongside the headcount. Team A knew what they needed. Team B knew what they were waiting for. Team C knew there was a change outstanding. Lars knew there were architectural decisions in the queue. Nobody had a complete picture, because the system for maintaining a complete picture had not been built. The original system was the shared room, the turned chairs, the hallway conversations. That system ran out of range somewhere between thirty and sixty people.

Heidi Helfand, who has spent years studying how software organizations actually grow and reorganize, makes a point that cuts through a lot of post-mortem blame: organizational growth doesn't just make a company bigger, it changes the coordination system. The informal mechanisms that carry a small team aren't just insufficient at scale. They actively create the conditions for invisible blocking. When everyone knows everything without trying, nobody builds the systems for knowing things on purpose. When the company grows past the range where informal knowing is possible, the gap is already structural, and it surfaces exactly where coordination is most needed, at handoffs between teams, between roles, between decisions that require someone to act without knowing they're blocking someone else.

This is the structural fact behind the Velox meeting that Maya is about to call.

The leadership that couldn't move it

Here is what Maya did when she saw the problem.

She called the meeting. She convened her CTO, her Head of Engineering, and her external Agile Coach. She gave them authority and time. She told them to find answers and to move faster. By any normal standard of organizational leadership, this response was correct.

And nothing moved.

The reason nothing moved is that Maya's mandate, "find answers, move faster", was aimed at a problem that wasn't there. The problem she was trying to solve was: the team doesn't have the right answer yet. The problem that actually existed was: the system produces delays structurally, independent of whether anyone is working on finding better answers.

You've probably been in a version of this room. The leadership is capable and engaged. The intent is right. The authority is genuinely given. And the situation barely shifts. What makes this particular kind of stuck so hard to name is that there is no bad actor. Maya is a good CEO who responded to a real problem with a real response. Lars and Priya are experienced, not slow. Kai is skilled, not misguided.

Well-run organizations stay exactly as stuck as badly-run ones when the issue is in the system, not in the people operating it. That's not a reassurance, it's a diagnostic fact. If you go into that meeting looking for the person who's moving too slowly or the team that's not collaborating, you will search for a while. And you will not find them. What you'll find instead are people who are doing their jobs correctly inside a coordination structure that isn't producing the outputs the company needs.

The meeting that Maya called can't solve this. Not because the people in the room aren't capable of solving it - they are. But because "find answers, move faster" is a response to the wrong question. The right question hasn't been asked yet: what is this organization, actually, as a system? And how does it work?