When Your Team Gets Too Big: Here's What Actually Worked

Six months of failed experiments. This is what we actually found.

Summer 2024. Our team hit fourteen people and everything suddenly felt off.

Standups dragged on for 45 minutes. Half the team stared at their screens, clearly not listening. We'd hear about shipped features in retrospect, usually when a client mentioned them.

Something had broken, and we weren't sure when.

When Things Started Going Sideways

Those daily check-ins? Pure torture. Marko would talk about his API work while Miloš stared at his phone, clearly thinking about lunch. Meanwhile, Darija was explaining her CSS struggles to a room full of backend developers who couldn't care less.

But here's the kicker: while we were all bored out of our minds in meetings, actual work was happening in the shadows. Someone would casually mention they'd just shipped a feature that none of us had heard about. Usually because Stefan from the marketing team had asked for "a quick favor" and our helpful engineers just... did it.

Our Failed Experiments (All of Them)

August 2024: The Split

We tried splitting into frontend and backend teams. Each team would have their own standup, their own focus.

Lasted one sprint. Turns out building Arheev requires both parts talking to each other constantly. Who knew?

September 2024: Async Updates

"Let's do daily Slack updates instead of meetings!"

First week, everyone posted detailed updates. Second week, updates got shorter. By week three, we were back to "worked on stuff" and nobody was reading them anyway.

October 2024: Rotating Team Leads

Different person leads standup each week, focusing on their area. Sounded great in theory.

In practice: some people ended up in every meeting (because they touched everything), others ghosted entirely. Created more silos, not fewer.

November 2024: We Almost Gave Up

Tried going back to "no formal process, just figure it out." Within two weeks we had the same problems as before.

Six months of failing. We were running out of ideas.

Early 2025: The Accidental Solution

We didn't plan this. Someone suggested we try mob programming for one particularly gnarly bug in Arheev.

Five people, one screen, working through a problem that touched frontend, backend, and database. We thought it'd be a one-time thing.

The bug got fixed. But something else happened: people learned parts of the codebase they'd never touched. The frontend developer understood why the database query was slow. The backend developer saw why the loading state mattered.

We started doing it weekly. Not for everything, but for complex features or tough bugs.

What Actually Changed

Knowledge spread faster. When everyone sees how something works, you don't end up with one person who's the only one who knows the deployment process.

Fewer "that's not my problem" moments. Hard to say the frontend isn't your concern when you just helped debug the React rendering issue.

Code reviews got better. People reviewing code they'd seen built live gave better feedback than people reviewing cold.

What's Still Broken

Let's be honest: we didn't solve everything.

Mob programming doesn't scale to 14 people. We usually have 4-6 in a session. Everyone else is doing their own work. So we still have coordination problems.

Some people hate it. Introverts especially. Sitting in a group coding session for two hours can be draining. We haven't figured out how to make it work for everyone.

We still get silos. Even with generalists, someone ends up being "the person who knows AWS" or "the person who understands the payment flow." Just... less than before.

AI tools help, but they're not magic. Yeah, you can use Claude to help write SQL when you're normally a frontend dev. But you still need to understand what you're doing. AI makes learning easier, not unnecessary.

Where We Are Now (November 2025)

Standups are down to 15 minutes. We actually talk about what matters instead of giving status reports.

Mob programming sessions happen 2-3 times a week. Not everyone participates every time. That's fine.

We still have coordination issues. We still have knowledge silos. But they're smaller and less painful than six months ago.

If You're Dealing With This

We wasted six months trying different approaches. Here's what we'd tell past us:

Don't split the team. Unless you're actually big enough (50+ people), splitting creates more problems than it solves.

Don't force everyone into generalists overnight. It's a gradual shift. Mob programming or pair programming helps, but it takes months, not weeks.

Accept that some specialization will happen. That's okay. Just make sure it's not the only person who knows something critical.

Try the 30% rule. If you're building a product alongside client work, reserve capacity. Otherwise it'll never get built.

Your mileage will vary. We're fourteen remote people building an HR platform. Your team, your product, your constraints are different.

But if your standups feel like a waste of time, and you keep finding out about work after it's done, you might have the same problems we had.

Unlike your favorite workplace sitcom, this story doesn't have a neat ending. We're still figuring it out as we grow.