The Parallel Trap: Why 'Busyness' Isn't Delivery

As a leader, one of the most common problems I see is a team that is working incredibly hard but delivering very little. Everyone is busy, tickets are being updated, but nothing is getting done.

The culprit is almost always the same: The Parallel Trap.

The 7-Person, 7-Project Team

Consider a hypothetical team lead facing this problem: "My team is working hard, but things are taking forever. I don't know how to structure our work."

I would start with two simple questions:

1. "How many people are on your team?"
2. "How many projects are you running in parallel?"

Suppose the answer is: "Seven people. Seven projects."

The reasoning sounds logical: "My stakeholders expect us to work on all these things."

This is the core misconception. Stakeholders don't want a team to work on seven things. They want the team to deliver seven things.

Starting all seven at once can leave every project waiting for scarce attention and expertise, rather than helping the team finish the most valuable work first.

A Thought Experiment: The 12-Project Year

To illustrate this, I use a simple thought experiment. Let's do the math.

Imagine you have a team of 12 engineers and 12 big projects to complete. For the sake of easy math, let's say each project takes exactly one engineer-year of effort.

You have two basic paths.

Path 1: The Parallel "Efficiency" Trap You assign one engineer to each project. Everyone starts on January 1st. What happens?

• Month 1-11: You deliver zero value. All 12 projects are "in progress."
• Month 12: You (in theory) deliver all 12 projects at the exact same time.
• Time-to-Value: Your first delivery is 12 months. Your average delivery time is 12 months.

Path 2: The Sequential Delivery Model You swarm all 12 engineers onto Project 1. (Again, for the sake of math, let's assume 12 people can finish a 1-year project in 1 month).

• End of Month 1: Project 1 is delivered. You've provided value.
• End of Month 2: Project 2 is delivered.
• End of Month 3: Project 3 is delivered.
• ...and so on.
• End of Month 12: All 12 projects are delivered.
• Time-to-Value: Your first delivery is 1 month. Your average delivery time is 6.5 months.

The stakeholder who gets their project in Month 1 is ecstatic. The stakeholder who gets theirs in Month 12 is no worse off than they were in the parallel model. You have provided 11 other projects worth of value to the company while they were waiting.

It's Not Just About the Math

The numbers are compelling, but the human benefits of sequential delivery are even more important:

1. Morale: The parallel team gets one "win" all year, right at the end. The sequential team gets 12 "wins," one every single month. They build momentum and feel a constant sense of accomplishment.
2. Knowledge Sharing: In the parallel model, 12 people work alone. In the sequential model, 12 people work together on 12 different projects. Knowledge spreads, skills are shared, and everyone learns from each other.
3. Growth: People grow by working together and tackling new challenges. The sequential model is a growth-accelerator.

The "But..." (And How to Account for It)

Now, I know it's not this linear. Adding 12 people to a project doesn't magically make it 12x faster (Brooks's Law is real).

Another common pushback is about specialists: "I'm the only front-end engineer, and this is a back-end task. What do I do?" This is a valid concern. I value T-shaped people—people with a deep specialty and an interest in learning across boundaries—but that flexibility takes investment. Pairing, knowledge sharing, and time to learn help make collaboration possible. Simply assigning everyone to the same project doesn't.

From Theory to Practice: The WIP Limit

The lesson isn't "all work must be sequential." It's that unnecessary parallelism delays value. This is why I am a huge proponent of limiting Work in Progress (WIP).

My practical recommendation is to agree on a small, team-wide WIP limit, then adjust it based on what helps work flow. This isn't about an individual's task count; it's about the team's total in-flight work, its dependencies, and where people can genuinely help one another.

A useful WIP limit encourages focus and collaboration: finish something before pulling in the next item. Apply that at the level where collaboration actually happens. A large organization isn't one giant team, and one universal limit won't make sense for every group.

The job is to see past the "busyness" illusion and focus on what matters: delivery.