Your Team Structure Made Sense at 10 Engineers.
It Doesn't at 40.

Most software companies start with a flat structure. Everybody reports to the CTO or the VP of Engineering. Communication is informal. Decisions happen fast. The team ships, learns, and adjusts.

Then the team grows. A few managers get added. Sometimes a middle layer. And then, almost without exception, delivery gets slower, quality gets harder to maintain, and engineers start leaving.

The structure didn't break because the people got worse. It broke because nobody redesigned it.

The Two Groupings Every Growing Engineering Organization Needs

There is a conceptual distinction that most engineering organizations either conflate or never make explicit, and it causes more organizational drag than almost any other single factor.

You need departments. And you need business units. They are not the same thing, and they should not be run the same way.

Departments are organized by expertise. Engineering, product, design, QA, DevOps, data science, business intelligence. Their purpose is to maintain standards, develop careers, and deepen expertise. Departments are where technical growth happens. They give engineers a professional home.

Business units are organized by product or goal. A cross-functional team with a product manager, one or more engineers, a QA engineer, and a designer, all working on the same product area. Their purpose is delivery. The PM and the Engineering Manager lead the unit as a duo. The business unit is where product gets built.

Conflating the two is the most common structural mistake in growing software organizations. When you have a frontend department and a backend department and a QA department, every feature requires coordination across three separate management chains. At 10 engineers, that's a conversation. At 40 engineers, it's a dependency web that slows everything down.

The departments handle career development, technical standards, and expertise. The business units handle execution. Both exist, simultaneously, in the same organization. The reporting line for career purposes runs through the department. The working relationship for delivery purposes lives in the business unit.

---

Figure 1. Functional silos force coordination across separate chains of command. Cross-functional business units eliminate it.

---

The Product Team Unit That Works

Within the business unit model, one of the most effective patterns has three elements.

A Product Manager and an Engineering Manager as co-leads. Not one above the other. They own different domains with no overlap: the PM owns what gets built and why (the backlog, the requirements, the scope tradeoffs). The Engineering Manager owns how it gets built and whether the team can deliver it (the timeline, the task assignments, the execution). If a release slips, the Engineering Manager is accountable. If the wrong thing gets built, the PM is accountable. That clarity matters. Organizations that blur these two roles end up with neither person fully responsible for anything. In practice, tech leads, design, and platform dependencies all shape how decisions get made. The cleaner the PM/EM split, the less ambiguity accumulates under pressure.

QA embedded in the delivery team. Not as a gate at the end. Not as a separate department that the work flows through. As a member of the team, participating in planning, writing tests alongside features, catching issues in development rather than after release.

The QA gate model made sense when testing was manual and expensive. It doesn't make sense when most teams have the tools to cover the majority of tests through automation. When QA is a gate, it becomes the batching point where work accumulates, releases get delayed, and sprint planning stops reflecting reality. When QA is embedded, quality is part of the build process, not an audit of its output. This is one of the engineering practices that separate high performers from everyone else.

The same logic applies to DevOps. A DevOps function that sits outside the delivery team and controls deployment approvals becomes a bottleneck by design. Embedded DevOps, or a shared platform team that delivery teams pull from without seeking approval, keeps velocity where it belongs.

Shared Roles and Who Actually Owns Delivery

Not every role in a business unit is dedicated to a single team. At 30 to 50 engineers, a Product Manager often covers two product teams. A designer is frequently shared across three. A QA engineer may be the embedded member on one team while a QA lead covers standards across several. This is normal and workable, as long as accountability is clear.

The Engineering Manager is the person who makes shared roles workable. Because the EM owns delivery for their team specifically — the timeline, the task assignments, the day-to-day execution — it doesn't matter that the PM is splitting time or the designer is juggling three backlogs. Each team has one person accountable for whether work ships. That person is the EM.

This also answers a question that comes up often in mid-market companies: does the team need a project manager?

No. The EM is the project manager. They own the timeline, manage dependencies, assign work, and are accountable when delivery slips. Adding a dedicated project manager alongside an EM creates a third leadership voice in a team designed to have two. It produces coordination overhead, not less of it. If your Engineering Manager cannot handle the execution function, that is a hiring problem, not an org design problem.

How Expertise Standards Survive Embedded Teams

A reasonable objection: if QA and DevOps engineers are embedded in product teams, who maintains QA standards? Who sets DevOps practices across the organization?

The answer is guilds, chapters, or some equivalent cross-team discipline mechanism. A QA engineer reports to the Head of QA for career development, hiring standards, and technical practices. Day-to-day, they work inside a product team. The guild maintains expertise depth and cross-team consistency. The product team gets the embedded discipline without sacrificing standards. Both purposes are served without requiring a centralized approval chain.

The distinction worth holding onto: discipline leadership (who sets the standards, who develops the people) is different from centralized workflow control (who approves every release, who gates every deployment). The first is necessary. The second is the anti-pattern.

This is not a new concept. Organizations that scale well past 50 people without losing velocity tend to handle the tension between functional expertise and delivery speed this way.

Where Most Teams Go Wrong

The structural mistakes that show up repeatedly in growing software organizations follow a predictable pattern.

The first is blurred ownership between the PM and the Engineering Manager. When the PM starts assigning engineering tasks directly, or the Engineering Manager starts making scope decisions without the PM, the accountability split breaks down. Nobody owns delivery. Everyone owns pieces of it. The result is the same as having no owner at all.

The second is keeping QA and DevOps as centralized control functions. QA files tickets and blocks releases. DevOps becomes an approval gate for every deployment. Both functions were designed to raise the quality floor, but when they operate outside the delivery team, they raise the coordination cost instead. In PE-backed and mid-market companies, this is the single most common reason velocity degrades after a team reaches 30 to 40 people.

The third is missing the Engineering Manager role entirely. Early-stage companies often run without one, relying on a strong technical lead to manage both architecture and delivery. It works at 8 engineers. At 20, the absence of someone accountable for execution produces the appearance of agility: standups, sprints, retrospectives, without the output. The team is doing agile theater.

The Data and Analytics Problem

One structural decision that many mid-market software companies get wrong is keeping data science, data engineering, business intelligence, and research bundled inside the engineering organization.

These functions have different outputs, different time horizons, and different success criteria than product engineering. A data science team's work cycle for a model is measured in weeks or months. A product engineering team's work cycle for a feature is measured in days. When they share a backlog, the data science work either gets deprioritized perpetually (because it doesn't produce immediate, visible output) or it creates noise in the engineering cadence (because its progress is harder to measure in sprints).

Often the better answer is a dedicated Data Intelligence function that sits alongside engineering, not within it. That function owns BI, data science, data engineering, and research, and it reports to leadership with its own metrics and its own delivery cadence. Both groups tend to move faster when they're not competing for the same planning bandwidth.

Dunbar's Number and What It Means for Engineering Org Design

In 1992, British anthropologist Robin Dunbar published research showing that humans can maintain stable social relationships with roughly 150 people, constrained by the cognitive capacity of the primate neocortex.1 The number has been challenged and refined over the decades, but the core finding holds: somewhere between 100 and 200 people, organizational coherence starts to break down. Below that threshold, people know each other, trust is personal, and informal communication works. Above it, you need hierarchy, rules, and formal processes to maintain coordination.

---

Figure 2. Key organizational inflection points as engineering teams grow. The structure that works at one stage becomes the constraint at the next.

---

The engineering-specific inflection points arrive earlier than 150.

At roughly 10 to 15 engineers, a flat structure works. Everyone knows everyone's work. The CTO can maintain direct context on every project.

Around 30 to 50 engineers, the flat structure often starts to break down. Communication channels multiply faster than the team can manage them informally. Decisions slow down. Most teams benefit from explicit team structures with clear ownership.2

By 80 to 120 engineers, many organizations need a full two-layer model. Departments for expertise and career development. Business units for delivery. Without it, you have a matrix organization with no clear accountability and no clear decision authority.

The companies that build the right structure at 40 engineers are not doing extra work. They are avoiding a reorganization at 120. A reorganization at 120 engineers is a multi-month distraction that produces attrition, reduces velocity, and occupies leadership bandwidth that should be going to product.

What This Means If You Are Hiring Your First Engineering Director

The structure decision should happen before the hire, not after. A new engineering director can change structure, but it is much harder than being handed a well-designed one. And an engineering director asked to lead an organization with fragmented accountability and no explicit team model will spend their first 12 months diagnosing problems that were already visible before they arrived.

Before hiring: define the business units that need to exist based on your products. Define the departments that will own standards and career development. Identify where QA currently lives and whether it needs to move. Determine whether data and analytics should remain inside engineering or move out.

Write it down. The same principle applies to engineering culture: a one-page organizational design document takes a day to produce and saves months of confusion after a senior hire.

The Pattern

Every engineering organization that scales well does a version of the same thing: they separate the structures that develop people from the structures that deliver product, they embed quality into the delivery team rather than appending it as a stage, and they revisit the org design before it becomes the bottleneck rather than after.

None of this requires an organization design consultant or a six-month transformation. It requires someone with authority to make the decision and the judgment to make it before the pain gets expensive.

---