As teams grow past 10 engineers, informal coordination breaks down. Here is the hierarchy, ratios, and org logic that keep large dev teams moving fast.
As a software development team grows past 10 or 15 engineers, the informal coordination that worked before starts to break down. Standups run long, PRs sit unreviewed, and no one is quite sure who owns which decisions. The fix is structural, not cultural.
The CTO and CPO sit at the top of the leadership structure and represent complementary halves of the same whole. The CTO owns the technical direction — the stack, the architecture, the engineering standards, and the development roadmap. The CPO owns the product vision — what gets built, in what order, and why it matters to users and to the business.
On a large team, their most important job is not making individual decisions. It is making the criteria for decisions clear enough that their direct reports can make them independently. A CTO who reviews every architectural choice becomes a bottleneck. A CPO who stays involved in every feature spec creates waiting. The leverage is in setting direction, not in holding approval authority.
Their collaboration also sets the cultural tone for how engineering and product interact at every level below them. When CTO and CPO are aligned, the team below them stays aligned. When they are not, that friction cascades down into every squad.
Fraction embeds experienced engineers, PMs, and fractional CTOs directly into your team — so you get the structure without the full-time cost.
Book an intro callNo lock-in. Start in as little as one week.
Below the CTO and CPO, the structure descends through directors and VPs, then engineering managers, then individual contributors — with product managers sitting parallel to engineering managers at the squad level.
Directors and VPs translate high-level goals into executable plans. They own prioritization across multiple squads, manage budget and resource allocation, and are accountable for aggregate delivery. Research into engineering org design consistently shows that this layer makes the largest difference to project success rates when it is staffed with people who can hold both technical and business context simultaneously.
Engineering managers run individual squads. They handle daily operations, code quality oversight, career development for their reports, and the translation of strategic goals into sprint-level tasks. A healthy span of control at this level is five to eight direct reports — enough to create real team cohesion, small enough to allow genuine coaching.
Individual contributors execute. Their value compounds when they have clear ownership boundaries, minimal context-switching, and a manager who shields them from organizational noise.
Squad model: a cross-functional team unit — typically five to eight people including engineers, a PM, and sometimes a designer — that owns a defined product area end-to-end and can ship independently without blocking other squads.
In a large organization, no single CTO can stay close to the technical details of every squad. The engineering manager fills that gap. They are the person who knows the codebase for their area, understands the technical debt, can make architectural decisions within their domain, and is accountable for the quality of what the squad ships.
This framing — engineering manager as team CTO — matters because it changes how you hire for the role and how much authority you give it. An engineering manager who is only managing calendars and running standups is underutilized and underempowered. The best engineering managers make real technical decisions, own the outcomes of those decisions, and treat their squad’s performance as a direct reflection of their leadership.
The practical consequence is that decisions stay close to the work. The engineering manager does not need to escalate every call about framework choice, refactoring priority, or code review standards. That autonomy is what keeps large teams moving at the velocity of small ones.
Product managers on large teams carry three distinct responsibilities that are easy to underestimate when you are still small. First, they translate market and user requirements into technical specifications that engineers can act on without ambiguity. Second, they own the project timeline — coordinating with stakeholders, communicating delays, and keeping the squad focused on the right priorities. Third, they are the final check on whether what ships matches what was specified.
That third responsibility is particularly important. Quality assurance at the feature level — does this actually do what we said it would do? — falls to the PM on most well-run teams. Automated testing catches regressions. The PM catches misalignment between intent and implementation.
On large teams, the PM also acts as a communication router. They receive context from leadership, filter it for the squad, and surface squad-level blockers upward. Without this role functioning well, squads either get too much noise from leadership or too little signal.
The widely recommended ratio is one PM for every three to four developers. At that ratio, each PM can stay close enough to the work to make good decisions without being stretched so thin that they become a bottleneck themselves.
Going below one PM per three developers does not necessarily improve things. A PM with only two engineers to support may spend too much time in execution details that engineers can handle themselves, rather than in stakeholder management and roadmap clarity where the PM’s judgment is genuinely needed.
Going above one PM per five or six developers is where the problems start. The PM cannot give adequate time to each project area, specifications get written too loosely, and developers end up making product decisions they should not have to make. The ratio is not just an efficiency measure — it is a decision quality measure.
| Ratio | Risk | Verdict |
|---|---|---|
| 1 PM : 1–2 devs | PM underutilized; over-involvement in execution | Too lean on engineering |
| 1 PM : 3–4 devs | Minimal — PM stays close to work without bottlenecking | Recommended |
| 1 PM : 5–6 devs | Specs get loose; developers fill product gaps | Stretched |
| 1 PM : 7+ devs | PM becomes a bottleneck; quality suffers across the board | Too thin |
Quality assurance on large teams is almost always a combination of automated and manual work — and the boundary between them is worth defining explicitly rather than leaving to convention.
Automated tests handle regression coverage: unit tests, integration tests, and end-to-end tests that run on every deploy and catch breakage before it reaches users. This layer should be owned by engineers, built into the development process, and treated as a first-class deliverable alongside the feature itself. The investment in this layer compounds over time and is the primary thing that lets large teams ship fast without accumulating defect debt.
Manual QA handles validation: does the feature do what was specified? Does the experience feel right? Does it interact correctly with adjacent features? This layer is where the PM’s involvement matters most, and it is the layer most likely to be skipped under deadline pressure — with predictable consequences.
Dedicated QA engineers make the most sense in domains where the cost of defects is highest: payments, authentication, data pipelines, and anything that involves regulated data. Outside of those domains, the combination of engineer-owned automation and PM-led manual validation covers most teams well.
Most high-performing teams follow the two-pizza rule: squads of five to eight people. At this size, communication overhead stays low, accountability is clear, and the team can ship independently without waiting on other groups. Beyond eight, coordination costs rise and velocity typically drops.
A healthy span of control for an engineering manager is five to eight direct reports. Fewer than five and the manager is underutilized; more than eight and they lose the ability to give meaningful feedback, run effective one-on-ones, and stay close to the technical work.
A ratio of one PM for every three to four developers is the widely recommended starting point for product-led teams. This gives each PM enough bandwidth to stay close to the roadmap, coordinate stakeholders, and maintain quality standards without spreading attention so thin that decisions slow down.
The most effective lever is structural: organize around independent product areas rather than technical layers. When each squad owns a vertical slice of the product end-to-end, most decisions stay inside the squad. Cross-team dependencies are the main driver of slowdowns, so minimizing them through org design matters more than communication tools alone.
The signal is usually around 10 to 15 engineers. Before that point, a single team with clear roles is simpler and faster. Past 15, a single manager can no longer keep context on all the work, standups take too long, and engineers start blocking each other. That is the right moment to split into named squads with ownership boundaries.
Not necessarily. Many mature teams shift QA responsibility to the engineers themselves, with automated test coverage as the baseline and manual exploratory testing handled by the PM or a shared QA resource. Dedicated QA engineers make the most sense for squads shipping high-risk features — payments, security, data pipelines — where the cost of a defect is high.
Praveen Ghanta is a five-time founder and serial entrepreneur. He is the founder of DevHawk.ai, an AI-powered engineering management platform, and Fraction.work, which connects fast-growing companies with top fractional tech and growth marketing talent. Previously, he founded HiddenLevers, a risk analytics platform for wealth management that he bootstrapped from inception to acquisition by Orion Advisor Solutions in 2021, serving thousands of advisors and $600B in assets. He earlier founded SmartWorkGroups, acquired by Intralinks in 2000.
Connect on LinkedIn →Describe your software or AI project. Get a full scope with story-point pricing, sprint estimates, and a downloadable plan in minutes. No calls, no waiting.
Scope Your Project for FreeWorking on a data strategy? Talk to a Fraction CTO. → Book an intro call
