The Team Is Growing, but Delivery Is Slowing Down? Why Engineering Teams Lose Efficiency While Scaling

The team keeps growing, but processes are not getting any better.

In situations like this, many companies struggle to admit a simple reality: headcount does not equal efficiency — and certainly does not equal team maturity.

In this article, I want to talk about a common problem many engineering organizations face: the loss of efficiency during scaling. In my role as Head of PHP/Go Department at UPSTARS — a company that is actively growing — I work directly with the challenges discussed below.

Let’s begin.

Why Teams Start “Slowing Down” as They Grow

The team grows: first 2–3 developers, then 5–10, later 30+.

And at some point, everything starts slowing down. Features take longer to deliver, decisions drag on, and people begin bypassing processes in the name of speed.

Usually, in such cases, the team structure no longer matches the scale of the system. This is a specific manifestation of Conway’s Law: system architecture reflects the communication structures of the people building it.

That is why restructuring is an architectural decision.

The structure you design today will become your architecture a year from now.

Three Models — But Not Three Stages

In this article, I’ll walk through three organizational models I’ve personally encountered: linear, matrix, and cross-functional.

These are not mandatory stages every company must pass through.

Many companies spend decades operating successfully within a matrix structure. Some startups begin as cross-functional organizations from day one. Amazon, at one point, scaled a highly linear model surprisingly far through the concept of single-threaded leaders.

These are different answers to different organizational problems — not maturity levels.

When It’s Time to Rethink the Structure: Universal Signals

Several warning signs are universal regardless of organizational structure:

• people bypass processes to move faster;
• decisions take weeks instead of days;
• informal agreements replace formal processes;
• Heads and CTOs spend increasing amounts of time manually synchronizing teams.

These are indicators that the current structure no longer scales effectively. If you notice two or more of them consistently, it is time to rethink the organization.

The same issues may also result from:

• incompetent management;
• toxic culture;
• weak tooling;
• unclear strategy.

Before rebuilding the structure, verify whether the structure is actually the root problem. Restructuring for the sake of restructuring simply moves friction elsewhere and creates months of organizational cleanup.

The Linear Model — The Strengths and Limits of a Single Center

When people think about engineering team management, the first role that comes to mind is usually the Team Lead — not a People Partner or Product Manager.

In a linear structure, the Team Lead combines several responsibilities at once:

• technical leadership;
• people management;
• delivery coordination.

The advantage is obvious: the team always knows where decisions come from, and expertise is concentrated in one place.

How Many People Can a Linear Structure Support?

At the team level, the “two-pizza rule” usually works well — roughly 6–8 people.

Several such teams can be grouped into a linear hierarchy under one Team Lead. Typical span-of-control principles suggest that one manager can effectively handle around 5–10 direct reports. With one layer of sub-leads, this usually scales to approximately 25–30 people.

Of course, the exact number is conditional.

The real limit appears when the Team Lead can no longer hold the entire system in their head simultaneously:

• architecture;
• operational issues;
• people management;
• priorities.

The Main Trap: Bottleneck and Knowledge Keeper

The core problem of the linear model: the Team Lead becomes both the bottleneck and the primary holder of critical context.

Every decision flows through a single person.

As a result:

• technical quality starts suffering;
• delivery speed decreases.

When all architectural knowledge and context are concentrated in one individual, the organization becomes dependent on a person instead of resilient processes.

How to Improve the Linear Model

Several practices genuinely help:

• allow Senior Engineers to communicate directly with the business on technical details;
• treat the Team Lead as a facilitator rather than an intermediary;
• document architectural decisions collectively through ADRs to eliminate “oral architecture”;
• rotate engineers between modules gradually to reduce knowledge silos and improve the Bus Factor;
• assign Maintainers for specific system domains to distribute ownership more evenly.

In this form, the linear structure works well for smaller teams or service-oriented organizations.

However, in product companies, it quickly runs into communication scaling limits.

The symptoms are usually obvious:

• the Team Lead becomes a bottleneck;
• approvals slow down;
• people begin coordinating informally.

At that point, transitioning to another model becomes almost inevitable.

The Matrix Model — Controlled Conflict

If the linear structure centralizes authority around the Team Lead, the matrix model introduces two management dimensions:

• technical leadership (TL);
• product leadership (PM).

In theory, this creates a system of checks and balances:

• the TL owns the “how”;
• the PM owns the “what” and “when”.

In practice, the matrix model often functions as controlled conflict. The moment interaction rules become unclear, the system starts degrading.

How Matrix Structures Degrade

The most common failure scenario happens when:

• a Team Lead brings “linear model” habits into the matrix and starts defining product priorities independently;
• or a Product Manager ignores technical constraints for the sake of speed.

In both cases, balance collapses.

The organization either:

• degrades technically;
• or loses delivery velocity.

Another strong warning sign appears when engineers receive tasks from two independent sources and start interpreting conflicting priorities.

Product quality deteriorates quickly in that environment.

Safeguards Without Which the Matrix Fails

A clear responsibility framework, such as DACI or RACI, is essential.

It must explicitly define:

• architecture and technical decisions as the TL’s domain;
• priorities and timelines are the PM’s responsibility.

Shared OKRs help align incentives: initiatives like SLOs, SLIs, or observability should stop being perceived as “developer concerns” and instead become part of business outcomes.

Escalation rules are equally important.

For example:

Limiting unresolved management conflicts to 24 hours prevents disagreements from blocking the team indefinitely. The exact time itself matters less than the existence of a hard escalation boundary.

In a healthy matrix organization, conflict becomes a balancing mechanism rather than a dysfunction.

This model works particularly well for medium-sized product organizations — roughly 20–80 people.

Its cost is permanent balance management.

The typical failure signal is straightforward: disputed decisions increasingly escalate to Heads or CTOs because TLs and PMs stop resolving conflicts independently.

The Cross-Functional Model — Autonomy Comes at a Cost

Eventually, even matrix structures begin to slow down.

Developers, QA engineers, and analysts start coordinating directly with each other outside formal management chains simply because it is faster. That is usually a sign that the coordination cost between teams has become too high.

At this stage, the team effectively begins mutating on its own:

• taking broader ownership;
• blurring role boundaries inside delivery processes.

What initially looked like “process bypassing” gradually becomes the new operating model.

From there, organizations usually choose between two paths:

• enforcing centralized control again;
• or formalizing the new behavior.

The second path leads toward cross-functional teams. At the same time, this model should not be romanticized.

Cross-functional structures work well only when value creation can be localized within the team itself.

If the system depends heavily on centralized services — platform engineering, compliance, shared infrastructure — cross-functionality may actually increase coordination costs instead of reducing them.

Team Topologies and Spotify: Two Different Schools Behind One Concept

What the industry usually calls the “cross-functional model” is actually a combination of two distinct schools of thought.

The first is Team Topologies (Skelton & Pais), where the key metric is team cognitive load.

The second comes from the Spotify model:

• Squads;
• Tribes;
• Guilds;
• Chapters.

Most companies combine ideas from both approaches in their own way, which is why implementations vary so dramatically.

What Is a Cross-Functional Team?

A cross-functional team is an autonomous unit that contains all competencies necessary to create value within a specific product or domain.

It combines:

• engineering;
• design;
• analytics;
• testing;
• product management.

And it can execute the full cycle from idea to delivery.

The key distinction from a traditional feature team is important: the team owns a problem and a business metric — not just a predefined feature roadmap.

If tasks still arrive as a fixed quarterly scope from above, the organization is only cross-functional on paper.

Team API — The Interface Between Teams

The primary advantage of this structure is reduced inter-team dependency.

Because the team owns the delivery end-to-end, a large portion of the coordination cost simply disappears.

However, complexity does not vanish — it moves into the Team API: a set of explicit contracts between teams.

This includes:

• APIs and integrations;
• change management rules;
• compatibility ownership;
• stability expectations.

Which Roles Hold the System Together?

In this model, role clarity becomes critically important.

• Tech Leads own technical decisions and integrations;
• Product Owners own priorities and business context;
• Engineering Managers own delivery, people, and operational processes.

When one person starts combining multiple responsibilities, the structure gradually degrades back into either a linear or matrix organization.

Staff and Principal Engineers also become increasingly important. They operate across teams:

• aligning architecture;
• driving RFCs;
• reducing coordination costs without introducing additional management layers.

In large systems, this becomes one of the key scaling mechanisms.

What Cross-Functional Organizations Cannot Scale Without

For cross-functional organizations, safeguards are not optional — they are foundational. Without them, autonomy quickly turns into chaos.

Several elements become essential:

• Team API as a formal contract model between teams;
• clearly defined TL/PO/EM role boundaries;
• Guilds and Chapters that maintain common standards around architecture, testing, CI/CD, and observability;
• contract testing that allows services to evolve safely;
• outcome-based metrics such as Product OKRs.

Without these mechanisms, autonomy easily degrades into a “technology zoo” where every team optimizes locally while the system degrades globally.

This model makes the most sense in products with:

• complex domains;
• many inter-team dependencies;
• high scaling requirements.

Its price is significantly higher due to engineering maturity:

• code culture;
• automation;
• code review discipline;
• documentation habits.

Without those, the model simply does not scale.

Structure Is an Architectural Decision

Every organizational model fails in predictable ways.

The degradation signals are often similar — the difference is mostly where the friction appears. If you recognize those signals early enough, you can react before the system starts degrading on its own.

Transitioning between organizational models is always a tradeoff:

• less centralized control;
• more team ownership;
• higher process maturity requirements.

But if the degradation is not yet systemic, strengthening safeguards inside the current structure is often far cheaper than rebuilding the organization entirely. Otherwise, the problem simply relocates somewhere else.