Squads, Pods, or Just a Team? Structuring Engineering Under 30 People

The Consultant's Favorite Mistake

A founder tells me: "We're growing fast. We just hired our tenth engineer. We're thinking about moving to squads, with a squad lead on each team. Maybe platform as a service."

I ask: "Why?"

The answer is almost always the same: "Because we're scaling. That's what Spotify does. That's what Netflix does."

What I don't say out loud, but I think very loudly: You are not Spotify. You will never be Spotify. And copying Spotify's org structure when you have 15 engineers is like a startup buying enterprise software because Google uses it.

The difference between a team structure that works and one that creates overhead isn't Spotify envy. It's fit. It's knowing what problem you're actually solving and choosing the smallest structure that solves it.

I've seen this unfold a hundred times. Founder hires tenth engineer, suddenly becomes convinced that squads are the move. Adds a squad lead layer. Now the squad lead spends 30% of their time in stand-ups and retros and sync meetings, and 70% writing code badly because they're context-switching constantly. Engineering velocity decreases. Then they blame the structure.

The problem wasn't squads. It was premature structure.

The Actual Stages

Here's how I think about org structure for engineering teams:

Stage 1: One Team (0-10 engineers) You don't have a team structure. You have a team. Everyone reports to the VP/head of engineering or to the founder. You do all-hands stand-ups. You have one Slack channel. You probably deploy together once or twice a week.

This works until you can't fit everyone in one room during sprint planning. Then you're done.

Stage 2: Feature Teams (10-20 engineers) You're big enough that you need separation of concerns, but not big enough to justify formal structure. You split by feature or product area. There are two or three teams. They have informal leads (often whoever is most senior). They coordinate through async updates and weekly syncs.

This works until the teams can't see each other's work and are rebuilding the same thing. Or until you have two leads who don't agree on architecture and it creates gridlock.

Stage 3: Verticals + Platform (20-40 engineers) Now you have distinct product teams (built around customer outcomes or features) and a platform/infrastructure team. Product teams move fast. Platform team manages shared systems that multiple product teams depend on.

This is when you need a real structure. Real lead roles. Clear boundaries. Formal interfaces.

Stage 4: Multiple Platforms (40+ engineers) You have enough people that you can sustain specialization. You have a platform team, maybe a data team, maybe infrastructure ops, maybe security. You have multiple product teams. This is when you can actually do the Spotify model and have it make sense.

Most startups fail before they get here. And the ones that do get here shouldn't copy Spotify's structure exactly—they should adapt it to their own reality.

Stage 2 in Detail: What Actually Works at 10-15 People

Let me spend time here because this is where most of the decisions I see go wrong.

You have roughly 15 engineers (including yourself if you're an eng founder). You have maybe two customers per month in your top tier. You're adding features every week. You have maybe two or three things shipping that are real architectural changes.

Here's the structure that works:

One engineering lead. This person reports to the founder or product lead. They own:

Technical hiring
Roadmap (in collaboration with product)
Code quality standards
Mentorship of the junior engineers

They write code 50% of the time. They're in engineering meetings the other 50%. They're not managing anyone formally—you can't manage that densely at this stage. But they are the person who knows what everyone is working on and why.

Two product/feature teams.

Team A: 6-7 engineers (maybe one senior, three mid-level, 2-3 juniors)
Team B: 6-7 engineers (maybe one senior, three mid-level, 2-3 juniors)

Each team owns an area of the product. They have a senior engineer on it who acts as a technical voice—not a manager, just the person who's been there longer. That senior takes on code reviews, sometimes helps unblock juniors, sits in architectural discussions.

Teams coordinate through a weekly 30-minute sync where they talk about dependencies and share what shipped.

One platform/shared context person. This is often a very strong mid-level engineer or a senior engineer who's taking a step sideways from pure IC work. They own:

Deployment infrastructure
Database changes
Shared libraries
Local dev environment quality

Everyone on both teams can open issues or PRs here. The platform person owns the backlog. They prioritize based on which product team is most blocked.

This structure works because:

There's a clear escalation path (to the engineering lead)
There's somebody thinking about shared systems (the platform person)
There's enough delegation that the engineering lead isn't a bottleneck
There's not so much structure that you're spending 20% of engineering time in sync meetings

The overhead is real but not killer.

Stage 3: When You Have to Actually Formalize

When you hit 20-25 people, the two-team structure breaks. You probably have more like four feature teams now. And you have three senior engineers who all have slightly different opinions about what the architecture should be.

Now you need:

Team leads on each product team (formally responsible for shipping their roadmap, mentorship, and code quality on their team)
Leads sync once a week where the leads think together about dependencies, bottlenecks, and strategy
A platform/infrastructure team (probably 3-4 people) who own shared systems
A tech lead or architect role (not managing people, but thinking about technical direction across the whole org)

The engineering lead role is now purely leadership—they're not writing code much anymore. They're doing hiring, career development, architecture disputes, and culture.

This is where squads could start to make sense. But I still wouldn't call them squads. That's consultant speak. Call them product teams. They're autonomous, they own a slice of the product, and they ship it.

The Counterpoint: Sometimes You Need the Structure Earlier

I just said not to add structure early. But there are exceptions.

If you have a really senior engineer joining your 12-person team, they're probably going to want some scope and autonomy. They might ask for a platform role or an infrastructure project. That's fine. You can offer it. Just don't create a whole org to give it to them.

If you're building something genuinely difficult (real-time systems, high-scale distributed systems, anything with serious reliability requirements), you might need platform investment earlier. But that's still "one person owns platform," not "we have a platform squad."

Also, if you're venture-backed and you know you're hiring to 50 people in the next 18 months, you might set up the structure you'll need in a year, rather than reorganizing twice. That's reasonable. But most founders do the opposite—they set up a structure for 50 people when they're at 15, and then they're drowning in process.

Real Example: The Over-Organized Early Stage

I worked with a founder who read all the right books on scaling and decided her 12-person engineering org needed:

A tech lead on each of the two teams
A platform team (one person)
A data analytics person
Weekly all-hands planning meetings
Formal sprint planning and retros

This was organized. It was also slow. Every decision went through a meeting. Every deployment was coordinated by the tech leads. The junior engineers weren't shipping because they were waiting for the tech lead to review and approve.

After three months, they were shipping half as fast as before the "structure" was in place.

We ripped most of it out. Kept one senior person acting informally as a guide for each team. Got rid of all the ceremonies except one weekly sync. Let teams deploy when they wanted. Suddenly they were faster again.

The structure wasn't bad. It was just too much structure for the stage of the company.

Where I Come In

If you're between 12 and 30 engineers and you're not sure whether you need to reorganize, I'll help you figure it out. I'll look at your bottlenecks, your team composition, your shipping velocity, and recommend the smallest structure that solves your actual problems—not the structure that sounded cool in a book.

Let's talk about your org.

Your Action Checklist

List out your current bottlenecks. What's slowing feature shipping the most?
Count your engineers by level. How many seniors? How many mid-level? How many juniors?
Map what you're actually shipping. Are features owned clearly, or do multiple people have to coordinate?
If you have under 15 engineers, you probably don't need formal team leads. You need clear senior voices.
If you have 15-25 engineers, you probably need two clear product teams with informal leads and some platform ownership.
If you have 25+, you need to formalize leads and probably start thinking about a dedicated platform team.
If you've reorganized in the last 6 months, don't do it again until you've measured the impact. Give changes time to work.

The Real CTA

Your org structure should be invisible. If people are spending time thinking about the structure instead of shipping, it's wrong.