Why I Set a Speed Limit for Projects in a Multi-Project Team

The Odd Cycle of Parallel Projects: Everything Moves, Nothing Gets Done

For the past two years, our team often worked on three or four projects at the same time. On the surface, every project had someone on it, and every week there was progress to report. But when a critical milestone came, one project would always get stuck.

At first I thought it was a resource problem, so I hired more people and shuffled the team around. Later I realized the real issue wasn't people — it was that every project was moving at a snail's pace.

Speed Limit: A Counterintuitive Constraint

What I came to understand is this: for a small team, the thing you actually need to manage during parallel projects is not resource allocation but the "speed" of each project.

By "speed limit," I don't mean limiting how hard people work. I mean limiting how many projects are in a state of "full-speed" at the same time.

Let me give an example. Suppose we had three projects: A was the core product iteration, B was a supporting activity, and C was an exploratory new feature. In the past, we put equal effort into all three, and each one made some progress every week. But the actual result was: A's development kept getting interrupted by B's urgent requests, C stalled mid-way because the direction wasn't clear, and in the end all three were delayed.

So we set a rule: at any given time, only one project can be at "full speed." The others are either frozen or slowed down to a "cruise" state.

Why does this work?

Because the cost of context switching in a small team is much higher than in a large company. If a person is on two projects at once, just switching their brain between them takes a lot of time. And the hidden dependencies between projects — like sharing the same designer or the same test environment — push the switching cost to grow exponentially.

How to Decide Which Project Gets Full Speed

I used two dimensions to make the call:

First, does this project have a clear external delivery deadline? For example, a date promised to a client, an app store review schedule, or a fixed launch date for an event. Projects with external deadlines naturally get higher priority, because the cost of delay is visible.

Second, is this project currently in a state of "momentum"? What do I mean by that? The requirements are clear, the solution has been validated, and the code is more than half written. In that case, interrupting it causes the most damage. Conversely, if the project is still in the exploration phase, pausing it for a month causes relatively limited loss.

With these two dimensions, the decision becomes simple: the closer the external deadline and the greater the momentum, the more this project deserves full speed.

Putting the Speed Limit into Practice

Three things we actually did:

First, identify the full-speed project. At the start of each iteration, everyone on the team knows which project is the "protagonist" this week. All other projects are in a lowered state by default.

Second, give the slowed-down projects a "freeze" switch. They're not completely abandoned — we record the current state and define the restart conditions. Like, "We'll continue B after A ships." The psychological benefit is that people don't worry about things being forgotten, so they can focus on the current project.

Third, reassess every week. The full-speed project isn't fixed. If external deadlines change, or a new blocker appears, we re-prioritize.

After running this system for six months, the biggest change wasn't fewer delays — it was better team morale. Before, people worried, "Is that other thing being ignored?" Now with clear rules, that anxiety is gone.

How This Rule Can Fail

Of course, this rule has clear boundaries.

The most typical failure is: we speed up a project, but its external dependencies can't keep up — like a third-party SDK having issues, or a client not confirming requirements. Then full-speed becomes spinning wheels, wasting the team's time.

Another failure: we misjudge a project's momentum. Sometimes we think a project is stable, but the core logic hasn't been validated yet. We push it at full speed, hit the halfway point, discover the direction was wrong, and have to start over.

So this rule isn't a silver bullet. It fits best when requirements are relatively clear and external deadlines are well-defined. If the project is in a highly uncertain exploration phase, a speed limit doesn't help much — it's better to freeze it entirely and put your energy into something you're more confident about.

If You're Also Stuck in the Mud of Parallel Projects

If you're running multiple projects at once, my advice is: don't rush to hire more people. First check whether too many projects are running at "half speed."

Try picking one project, giving it full speed, and slowing down or freezing the others for a month. Then see if the full-speed project makes more progress in that month than all three projects combined did before.

If it works, you can turn the rule into a permanent practice. If it doesn't, your problem might be elsewhere — maybe the project direction itself is wrong, or the team's collaboration has deeper issues.

Either way, the experiment is cheap. Worth trying.

PaxLee