Five Months Late, They Expanded the Offshore Team to 60 Engineers. It Got Later.

Stride's Career-as-a-Platform team was five months past its launch date when I got involved, and leadership had already tried everything they could think of. They hired a product manager, who quit after two months. They cycled through three project managers. They brought in consultants at $40,000 a month. They expanded the offshore engineering contract to 60 people.

Every one of those moves added capacity, and every attempt made things slower and more expensive.

This isn't a story about bad people or a bad vendor. The team had a meaningful mission – helping high school students who weren't headed to college find pathways into good jobs – and a lot of talented people working on it. Nobody on that team lacked effort. They lacked something else, and adding more people couldn't supply it.

Every fix added people, and every fix made it slower

The reflex makes sense from the outside. A project is late, so it needs more hands, and if one product manager can't fix it, maybe the project managers can, and if they can't, maybe the consultants can, and if none of that works, at least more engineers will write more code.

Inside a team like that, every new arrival has to be brought up to speed by people who are already overloaded, and every new person becomes another node in the conversation. At Stride that conversation was already running eight hours a day on Zoom. The team was working synchronously from morning to night, with product, design and engineering all trying to figure things out together in real time, and adding people to that meeting only made the meeting bigger.

The most striking number came out of the code repository. Out of 60 offshore engineers, only a handful were contributing meaningful code. Most commits came from the same few developers, and two people were doing the bulk of the code review. Leadership had paid for 60 engineers and was effectively getting a small team, plus the cost of coordinating all the others.

What Brooks's law actually says

None of this would have surprised Fred Brooks. In The Mythical Man-Month, published in 1975, he wrote the line every engineering leader eventually hears: adding people to a late software project makes it later. What gets quoted less is how he introduced it. "Oversimplifying outrageously," he wrote, "we state Brooks's Law."

He named two costs. The first is training, because new people have to learn the technology, the goals and the plan from the people who already know them, and that cost can't be split up. It grows with every hire. The second is intercommunication. If every person has to coordinate with every other person, the number of channels grows as n(n−1)/2, so three people need three times the pairwise coordination of two, and four need six times as much. At Stride's scale that math turns ugly fast.

Brooks's own advice for a late project wasn't to hire. It was to reschedule or to trim the task. Repeating the hiring cycle, he wrote, is where "madness" lies.

Why adding people makes a late team later

The mechanism has been studied a lot in the decades since Brooks wrote that, and the research describes Stride almost step for step.

Abdel-Hamid and Madnick at MIT modeled it as a vicious cycle: adding people raises communication and training overhead, which lowers productivity, which delays the project further, "which can trigger an additional round of work force additions." That's a product manager, then three project managers, then consultants, then 60 engineers, drawn as a system-dynamics diagram.

Ramp-up time is longer than most leaders budget for. Zhou and Mockus found that rapid influxes of new developers from outsourcing and offshoring lower productivity and delay projects, and that newcomer productivity took a few months to plateau on small and medium projects and up to 12 months on a large one. Google's own developer-productivity researchers found that new engineers took about 19 weeks to ramp up before the pandemic and about 22 weeks after. A late team doesn't have five months to spare for each new hire to become useful.

Bigger teams tend to be less productive per person, too. A study of projects in the ISBSG benchmark database by Rodríguez and colleagues found that projects with an average team size of nine or more were less productive than smaller ones, and the gap held up under statistical testing.

Adding people works on clear work, and late teams don't have clear work

Brooks's law isn't settled physics, and the places where it breaks down are the useful part.

A 1999 simulation by Hsia, Hsu and Kung found that adding people to a late project always increases its cost, but the project doesn't always get later. Whether it does depends on how sequential the remaining work is and how early the people arrive. Open source pushes back harder. A study of more than 46,000 SourceForge projects by Schweik and colleagues found that more developers predicted success, and Capiluppi and Adams found that KDE at more than 300 developers needed about the same communication as it had at 10, because the work was modular and the coordination stayed inside a small core team. A five-year study of a Cisco product by Meneely, Rotella and Williams found that steady team growth went along with better quality later on, while accelerated expansion went along with worse quality.

Read those together and they point in the same direction. More people help when the work is clearly specified, divided into pieces that don't depend on each other, and added early and steadily. Those are all conditions of clarity. A late team is usually late precisely because it doesn't have clarity yet, which means it's the team least able to absorb new people.

At Stride, requirements were being worked out live in meetings, designers were drawing mockups in real time during calls, and engineers were coding before anyone understood the requirements. There was no definition of done. Sixty engineers had nothing stable to divide among themselves, and as the case study puts it, even the productive engineers couldn't be effective in that environment.

What was actually constraining the team

The pattern I see over and over is that when everything downstream is failing, the cause is upstream – an unmade decision or an unasked question flowing downhill into everything it touches. The engineers at Stride looked like the bottleneck because they were at the bottom of that waterfall.

So I started with a question that sounds too simple to be useful, and asked it about every piece of work: why are we building this? The vast majority of the time, there was no user-centric answer. It was "we thought we should" or "an executive told us to." Sprint planning started at 8 AM and was still going at 6 PM, and eight hours of meetings felt productive because everyone was doing something. The team was confusing motion with progress.

The fix changed how the team worked, not who was on it. Nobody was laid off. Product, design and engineering each got protected time to think, communication went async-first with deliberate points of contact, requirements had to exist before build work started, and the team adopted a real definition of done with automated tests behind it. The first month, things actually got slower as I introduced the new processes. That's normal. By the end of 90 days, engineering throughput had tripled and cycle time had dropped 8x, per the case study, and the team shipped its first major release. Nobody new had to be hired to get there.

The 2026 version of the same reflex

The headcount reflex hasn't gone away. It's just started buying different things. When a team is behind today, the request often comes as more AI agents or coding tools instead of more contractors, and the same math applies to output poured into a system that can't absorb it.

LinearB's 2026 benchmarks found that AI-authored pull requests wait 4.6x longer before review starts. A study of projects adopting Cursor by He and colleagues found three to five times more lines added in the first month, gains that dissipated after two months, and code complexity up 41.6%. That's the Stride repository in a new costume: plenty of code arriving, and the same review queue and the same unclear requirements on the other end of it.

What to do instead when your team is late

Before you approve the next hire, contractor or tool, find out what the people you already have are actually waiting on. In my experience the answer is rarely "more hands." It's usually a decision nobody has made, a requirement nobody has written down, or a meeting that's eating the hours people would otherwise spend thinking.

Take Brooks's own advice seriously. Rescheduling and trimming the task both feel like admitting defeat, and both are cheaper than a second round of hiring that makes the date slip again.

If you're not sure where the constraint is, look at the work itself rather than the org chart: who's committing the code, who's doing the reviews, how long a ticket sits compared with how long it takes to do, and whether anyone can answer why it's being built. Those are the lenses I use, and at Stride they showed that capacity was never what was missing.

The 60 engineers weren't the root problem. Adding them was just the most expensive way to learn that headcount wasn't the constraint.