How an increase in capacity can initially slow you down

The Q1 Velocity Trap: Visualising the ‘Onboarding Dip’

In a previous blog post I discussed the Coordination Tax - how adding people creates permanent complexity noise in your team topology.

This time, I want to talk about something more immediate: The Capacity Trap.

It is mid-December. Every CTO I speak to right now has the same plan for Q1: “We are behind on the roadmap, but it’s fine. We have the budget approved to hire 4 engineers in January.”

The assumption is intuitive: Hiring in January = Speed in February.

But Operations Science tells us the reality is usually the opposite: Hiring in January = Chaos in February.

We tend to treat headcount like a simple addition sum: Current Team + New Hires = More Output.

But a new hire doesn’t just “add” capacity to a system; they “consume” it first. They need the codebase explained. They need their environment set up. Most importantly, they need their Pull Requests reviewed by your busiest Senior Engineers.

If your team is already running at 100% utilisation trying to hit deadlines, adding new people isn’t relief. It’s an anchor.

The Physics: Brooks’s Law

In 1975, Fred Brooks wrote The Mythical Man-Month, giving us the most famous law in software engineering:

“Adding manpower to a late software project makes it later.”

Fifty years later, we still ignore it. We assume that if we throw more bodies at the backlog, the burn-down chart will improve.

But let’s look at the specific math behind the law.

The Calculation: Net Capacity

To understand the real impact of hiring, we have to calculate Net Capacity.

The formula looks like this:

Net Capacity = Old Capacity - (New Hires × Training Drag)

Let’s run a scenario for a standard scaling team:

The Math: 4 New Hires × 0.2 (20% Drag) = 0.8

The Result: By hiring those 4 people, you have effectively removed 0.8 of a Senior Engineer from your delivery flow for the next 3 months.

You are paying a “Senior Tax” to buy “Junior Potential.”

The “J-Curve” of Velocity

This creates what we call the Onboarding Dip (or the J-Curve).

If you plot your team’s velocity on a graph, you expect it to go up in January. Instead, the physics dictates a specific curve:

  1. Phase 1 (The Dip): Velocity drops below baseline as Seniors focus on mentoring.
  2. Phase 2 (Recovery): New hires become net-neutral. Velocity returns to baseline.
  3. Phase 3 (Growth): New hires become net-positive. Velocity finally exceeds the old baseline.

The danger isn’t the dip itself - it is the expectation management.

If you told the Board that hiring in January would fix the Q1 delays, you are going to have a very difficult meeting in February when delivery slows down to accommodate the training.

The Hidden Cost: Context Switching

The maths above (20% drag) is actually generous. It assumes that the Senior Engineer loses 2 hours a day in a clean, solid block.

But in reality, that time is fragmented. It comes in the form of interruptions:

This fragmentation destroys Flow State. A Senior Engineer might only lose 20% of their hours, but they lose 50% of their “Deep Work” capacity.

How to Handle It

I am not saying you shouldn’t hire. You have to hire to grow. But you must respect the physics of the system.

  1. Forecast the Drag: Don’t promise speed in Q1. Promise capacity building in Q1 for speed in Q2.
  2. Limit Work in Progress (WIP): You cannot keep the same roadmap and do onboarding. Something has to give. Reduce the feature scope to make room for the training scope.
  3. Designate “Shields”: Don’t let new hires interrupt everyone. Assign one specific “Buddy” or “Mentor” per sprint to handle the questions, allowing the rest of the seniors to focus.

Calculate Your Debt

Before you sign those offer letters, you need to know exactly how deep your “Dip” will be.

At Capra Leadership, we combine the Psychology of People with the Physics of Flow to build engineering organisations that are mathematically efficient and culturally resilient.

See the dip before it happens. Download the calculators here.

References: