“We need more teams to deliver on time.”

by Cesario Ramos.

You have likely been faced with this challenge: “Should we hire more teams to speed up delivery because we are not going to meet our deadlines as things stand today.”

Fair question. But before you act…

• What if you’re right — will adding teams actually speed things up?
• What if you’re wrong — will it slow things down even more?

Brooks’ Law says: “Adding people to a late project makes it later.”

Why? Because more teams mean more dependencies, more coordination, and more chances for design mismatches.

Most of the time, adding teams won’t fix delivery problems. Good organizational design will.

Study Before You Act

At Creating Agile Organizations (CAO), we don’t throw teams at problems. We study how the system works:

• Dependencies
• Coordination overhead
• Capability gaps

We use proven tools like:

Design Structure Matrices (DSM)

Here is an example of using an Activity-DSM for task dependencies. You can see that there are multiple reciprocal task dependence between tasks, but the tasks are performed by different autonomous teams. Therefore, prioritisation conflicts, coordination costs, and cycle time increase, and eventually adaptability decreases.

figure 1. Activity DSM

Organizational-Architecture-DSM

Here is an example using an Organizational-Architecture-DSM to understand functional coupling between units. You can clearly see that:

• Business is responsible for exploring new partnerships and business models (with a focus on external growth opportunities).
• Product is responsible for developing and delivering new products efficiently (with a focus on internal capability and roadmap).

figure 2. Organizational Architecture DSM

These two goals conflict because:

• Business may push for partnerships or propositions that Product cannot deliver (capacity, technical fit, roadmap priorities).
• Product may prioritize roadmap efficiency and technical excellence, blocking or slowing Business initiatives.

The result: conflicting priorities, slow decision making, lower adaptability at the overall org-level.

Capability Gap Analysis

Here is an example using my favourite model: Jay Galbraith Star Model. You can see the gap between current team capabilities and desired team capabilities

figure 3. STAR Model with capability gap

…and, most important — common sense.

Sometimes, yes, you’ll still need more teams. But only after redesigning for clarity, flow, and adaptability.

Causal Loop Diagrams

Here is an example from my book Creating Agile Organizations. You can easily spot the problem of having adding more people without understanding the situation.

figure 4. Drifting goals CLD

“People get more specialized over time and eventually become single specialists. This archetype causes organizations to create dynamic teams to exactly match the concrete features or projects. Likewise, the organization grows to include more and more people.”

Why Is CAO Hard?

Because it’s easier to apply a shiny framework than fix hard design issues. It’s tempting to copy popular methods. And that’s fine — if you know what you’re doing… and you’re learning as you go.

It’s the System, Not the People

People, teams, tools — they’re easy to blame.
But systems thinking reminds us: “It’s the system, stupid.”

Most chronic Agile problems are design problems — not people problems.

What’s quietly killing agility in your organization? To fix it? study the system and design smarter. No framework required.

The CAO Way: Principles in Practice

In Creating Agile Organizations we first study to understand context then apply principle and proven guidelines.

1. Start With Strategic Focus
   Define the objectives that actually matter. Identify the capabilities needed to deliver them.
2. Find Real Capability Gaps
   Study how work flows. Find the real gaps before fixing what doesn’t need fixing.
3. Design Product Groups Around Value
   Form teams into product groups with a clear mission and customer value.
4. Loosely Couple Product Groups for Resilience
   Minimize dependencies. Let groups adapt independently.
5. Launch in Phases — Learn as You Go
   Roll out changes step by step. Adjust based on real results.
6. Measure Capability Development — Not Just Output
   Track how well you’re closing capability gaps. Keep improving.

And a useful reminder:
It’s rarely about adding teams. It’s about better design.