How Organizations Should Structure Teams and Sub-Teams
Organizations should structure teams and sub-teams around how work actually flows, not around an org chart drawn for its own sake. In practice, that means grouping people by function when the work is specialized and repeatable, by product or project when ownership and speed matter most, and always keeping sub-teams small enough that a handful of people can coordinate without a layer of meetings between them. The right team structure isn’t a fixed template. It’s a decision that should be revisited as the organization grows, because the structure that works for fifteen people breaks by fifty, and the one that works at fifty breaks again by two hundred.
I’ve been part of reorganizations that solved real problems and ones that just moved the confusion around. The difference rarely came down to which org chart looked cleanest on paper. It came down to whether the structure matched how people actually needed to talk to each other to get work done. A team split by function looks tidy until a single project needs five different departments to agree on priority. A team split by product looks agile until you realize three different product teams just built the same internal tool because nobody was talking to each other. Getting this right matters more than most organizations treat it, because team structure isn’t an HR decision. It’s the thing that determines whether your best work happens in weeks or gets stuck in hand-offs for months.
The Core Team Structure Models (And When Each One Actually Makes Sense)
Most team structures fall into a handful of well-established patterns. None of them is universally “best.” Each one trades off coordination speed against specialization depth, and the right pick depends entirely on what your organization needs more of at its current size.
Functional structure: People are grouped by skill or discipline, engineering together, marketing together, sales together. The US Chamber of Commerce describes this as a hierarchy based on the role of each employee, where specialists deepen their expertise by working alongside others who do the same kind of work. This works well early on, when depth of skill matters more than speed of coordination, and it tends to break down once a single initiative needs several departments to move in lockstep.
Divisional structure: Teams are split by product line, geography, or customer segment, each division operating with a fair amount of autonomy. This is common in companies with genuinely different product lines or regional markets that need locally tailored decisions rather than one central process trying to fit everyone.
Product- or market-focused structure: Similar to divisional, but the split is specifically around what’s being built rather than geography. TestGorilla notes this approach is common in manufacturing and tech companies where clarity of ownership over a specific product line drives faster decisions than a shared functional pool ever could.
Matrix structure: People report to both a functional lead and a project or product lead simultaneously. It’s powerful for organizations juggling many concurrent projects that all need specialized skills, but it comes with a real cost: dual reporting lines create ambiguity about whose priorities win when they conflict.
Here’s a quick comparison of when each structure tends to fit best:
How to Structure Sub-Teams Within a Larger Team
Once a team grows past the point where everyone can coordinate directly, usually somewhere around ten to twelve people, it needs to split into sub-teams. The mistake most organizations make here isn’t failing to split at all. It’s splitting along the wrong axis, which recreates the same coordination problems one level down.
There are two fundamentally different ways to divide a large team into sub-teams, and most real reorganizations end up blending both.
Horizontal division (by function or specialty): Sub-teams are organized around a type of work: an analysis team, a design team, a testing team, each handing off their piece to the next. This traces back to a Tayloristic model of grouping people by the kind of knowledge they apply. Educative’s research on this notes it works well for repeatable, well-defined work, but struggles the moment a project needs a lot of creative or holistic thinking that doesn’t decompose cleanly into hand-offs.
Vertical division (by feature or domain): Sub-teams instead own a slice of the actual product or business outcome end to end, sometimes called domain or feature teams. This avoids the hand-off delays of horizontal division, but it introduces a different risk: without every sub-team having every skill it needs, or without clear coordination, multiple sub-teams can end up quietly solving the same problem twice.
PMI’s research on organizing large teams adds a related, practical framework worth borrowing directly: sub-teams generally fall into component teams (each owning a subsystem or module), feature teams (each owning a full user-facing capability end to end), or functional teams (each owning a specialized stage of work like architecture, testing, or deployment).
On sub-team size specifically: The pattern that shows up consistently across agile research is that once a group gets past roughly ten to twelve people, it needs to be broken up, and once you’re coordinating twelve to fifty people across several sub-teams, they typically need a shared syncing mechanism between representatives of each sub-team, though this tends to lose effectiveness once you’re coordinating more than four or five sub-teams this way, requiring a more structured layer of coordination above it.
The more modern framing of this comes from Team Topologies, which groups sub-teams into four types based on what they actually deliver: stream-aligned teams that own outcomes and deliver value directly, platform teams that build shared services to accelerate the stream-aligned teams, enabling teams that temporarily lend specialized capability, and complicated-subsystem teams that own components requiring deep specialist knowledge. This model is worth adopting even outside of software teams, because it separates “who owns delivering value” from “who supports that delivery,” which is exactly the ambiguity that causes most sub-team coordination breakdowns.
How Sub-Teams Should Actually Coordinate Without Drowning in Meetings
Splitting a team into sub-teams solves the “too many people, not enough coordination” problem, but it immediately creates a new one: how do sub-teams stay aligned without turning every decision into a cross-team meeting? Most organizations solve this badly, either by over-coordinating, where every sub-team sends a representative to every other sub-team’s standup, or by under-coordinating, where sub-teams drift apart until two of them discover months later they built conflicting solutions to the same problem.
Team Topologies offers a genuinely useful framework here: three distinct interaction modes that define how any two teams should work together at a given moment. Collaboration is high-bandwidth, high-cost, and appropriate when two sub-teams are jointly discovering something neither fully understands yet. X-as-a-Service is low-cost and clearly bounded, appropriate once one sub-team simply consumes what another provides without needing to be involved in how it’s built. Facilitating is temporary and focused, appropriate when one sub-team is removing a specific obstacle for another and expects to step back once it’s resolved.
The reason this matters is that most coordination breakdowns come from mismatched expectations about which mode two teams are supposed to be in. A sub-team expecting an X-as-a-Service relationship, “just give me your output and I’ll build on it”, gets frustrated when another sub-team insists on constant collaboration for a decision that didn’t need it. Naming the mode explicitly, even informally, removes a huge amount of the friction that otherwise gets blamed on “communication problems.”
For coordination between many sub-teams at once, PMI’s research on large agile teams describes a common pattern worth adapting even outside of software: sub-teams each send one representative to a shared coordination meeting, sometimes called a Scrum of Scrums, to surface dependencies, blockers, and cross-team needs. Their research is candid about the limits of this, noting the format tends to fall apart once you’re coordinating more than four or five sub-teams this way, at which point a more structured layer of coordination becomes necessary.
Here’s a simple way to think about which coordination mechanism fits at each scale:
What makes most of this manageable in practice isn’t the meeting cadence itself; it’s whether every sub-team can see what every other sub-team is actually working on without having to ask. A shared workspace where projects and tasks are visible across teams removes a huge share of the need for coordination meetings in the first place, because the update that used to require a meeting is already visible the moment someone opens the workspace.
Common Mistakes When Structuring Teams (And Early Warning Signs)
Most team structure problems don’t announce themselves clearly. They show up as vague frustration, missed deadlines, or a sense that “communication” is the issue, when the actual root cause is a structure that no longer matches how the organization operates. Here are the mistakes I’ve seen repeatedly, and the early signals worth watching for.
| 1 | Structuring around people instead of work: It’s tempting to build a team structure around who’s already senior or who’s been there longest, rather than around what the actual workflow requires. This creates sub-teams that make sense on an org chart but not in practice, where the person best suited to make a decision isn’t the one with authority to make it. Early warning sign: Decisions routinely get escalated to someone outside the sub-team that owns the work, because authority and expertise don’t line up. |
| 2 | Never revisiting the structure as the organization grows: A functional structure that worked cleanly at fifteen people creates real bottlenecks at fifty, because every cross-department initiative now needs coordination across far more people than the structure was ever designed to handle. Early warning sign: The same handful of senior people are cc’d on every cross-team decision, because they’re the only ones with visibility across the structure as it currently stands. |
| 3 | Splitting sub-teams along the wrong axis: As covered earlier, horizontal (functional) division works for repeatable work but creates hand-off delays for creative or ambiguous work, while vertical (feature) division speeds up ownership but risks duplicated effort without coordination. Picking the wrong one for the type of work being done is one of the most common structural mistakes. Early warning sign: Two sub-teams discover, well after the fact, that they built overlapping or conflicting solutions to the same problem. |
| 4 | Treating the org chart as the source of truth instead of the actual workspace: A structure that exists only as a slide deck or an HR system, disconnected from where the actual work happens, drifts out of date almost immediately. People keep working the way they always have, regardless of what the latest reorg announcement said. Early warning sign: New hires get confused about who owns what, because the org chart says one thing and the actual working relationships say another. |
| 5 | Over-coordinating instead of trusting sub-team boundaries: Some organizations react to past coordination failures by adding more meetings, more approvals, and more cross-team check-ins, which slows every sub-team down without actually fixing the root misalignment. Early warning sign: Sub-teams spend more time in status meetings than actually producing the work those meetings are meant to track. |
A Practical Step-by-Step for Restructuring Teams and Sub-Teams
Restructuring a team is rarely as simple as redrawing boxes on an org chart. Done carelessly, it creates months of confusion. Done deliberately, it can meaningfully speed up how work moves through the organization. Here’s the approach I’ve found actually works.
| 1 | Map how work currently flows, not how the org chart says it should. Before changing anything, trace a handful of recent projects from start to finish. Note every hand-off, every approval, every point where work sat waiting for someone outside the immediate team. This reveals the real coordination pattern, which is often very different from what the official structure implies. |
| 2 | Identify where the current structure is creating friction. Using the warning signs from the previous section, look for decisions that get escalated too often, duplicated work between sub-teams, or senior people who’ve become unintentional bottlenecks simply because they’re the only ones with cross-team visibility. |
| 3 | Choose the structure that matches your current stage, not your ambitions. A twenty-person company doesn’t need the same structure as a two-hundred-person one, even if leadership hopes to get there eventually. Structuring for the size you’ll be in two years usually creates unnecessary overhead today. |
| 4 | Decide the sub-team division axis deliberately. Choose horizontal (functional) division for repeatable, well-defined work, and vertical (feature or domain) division for work that benefits from end-to-end ownership. Most organizations end up blending both: functional sub-teams for shared specialist services, feature sub-teams for product-facing work. |
| 5 | Define interaction modes between sub-teams explicitly. Borrowing from Team Topologies, decide upfront which sub-teams operate in a collaboration mode versus an X-as-a-Service mode versus a temporary facilitating mode. Naming this removes a huge amount of the ambiguity that otherwise gets blamed on poor communication. |
| 6 | Reflect the new structure in the actual tools teams use. A restructure announced in a meeting and never reflected anywhere teams actually work will quietly fail within a quarter. Sub-teams, ownership, and reporting lines need to be visible inside whatever platform teams use to manage their day-to-day work, not just in a static org chart. |
| 7 | Set a review cadence, not a “set it and forget it” structure. The organizations that avoid repeated painful reorgs are the ones that treat structure as something to revisit on a regular cadence, quarterly or at each significant growth milestone, rather than something fixed until it visibly breaks. |
None of these steps require an outside consultant or a company-wide announcement to execute well. They require being honest about how work actually flows today, and being willing to adjust the structure again once it stops matching that reality.
FAQs
What is the difference between a team structure and an organizational structure?
Organizational structure refers to the broader hierarchy of an entire company, departments, reporting lines, and leadership layers. Team structure refers to how a specific group of people within that organization is arranged to get work done, which can include functional divisions, sub-teams, and reporting relationships within a single department or project.
How many people should be on a sub-team?
Most research on team structure points to roughly ten to twelve people as the upper limit before a group needs to split into smaller sub-teams. Beyond that size, direct coordination between every member becomes difficult, and communication starts routing through fewer people, which slows decisions down and creates informal bottlenecks.
Should sub-teams be organized by function or by product?
It depends on the type of work. Functional (horizontal) division works well for repeatable, well-defined work where specialization matters more than end-to-end ownership. Product or feature (vertical) division works better for work that benefits from a single team owning an outcome from start to finish, though it requires each sub-team to have a broader mix of skills to avoid needing constant hand-offs.
How often should an organization revisit its team structure?
The organizations that avoid painful, disruptive reorganizations tend to review their structure on a regular cadence, quarterly or at clear growth milestones, rather than waiting until the structure has visibly broken down. A structure that worked at one size rarely holds up unchanged as the organization doubles or triples in headcount.
What’s the biggest sign that a team structure needs to change?
The clearest signal is when decisions routinely get escalated outside the sub-team that actually owns the work, because it means authority and expertise have drifted out of alignment. A close second is discovering that two sub-teams have unknowingly duplicated effort, which usually means the coordination mechanism between them has broken down.
Final Thoughts
Every organization I’ve watched struggle with team structure wasn’t lacking smart people or good intentions. They were working inside a structure that made sense at an earlier size or an earlier stage of the business, and nobody had deliberately revisited whether it still fit. Structure isn’t something you set once. It’s something that has to keep pace with how the organization actually grows and how work actually flows through it.
Structure that lives in the work, not just the org chart
I’d rather spend a week honestly mapping how work actually flows through my organization than spend another quarter watching decisions get stuck between sub-teams that were never given a clear way to coordinate. That’s the real case for getting team structure right: not a cleaner org chart, but a structure where ownership, coordination, and visibility are built into how the organization actually works, which is exactly what a team management platform like Techxaro One is built to support.
