Small Teams, Big Models: Why 15 Engineers Now Ship Like 200

I run a team of 15 engineers. Last quarter we delivered a platform that our client's internal estimate had pegged at 18 months with a team of 40. We did it in 14 weeks with 12 people.

I'm not saying this to brag. I'm saying it because I think most engineering organizations haven't caught up to what's actually possible when you combine sharp people with good AI tooling and resist the urge to grow headcount as a first response to every capacity problem. The math has changed. A lot of teams are still running on the old math.

The Coordination Problem Nobody Talks About Honestly

Fred Brooks told us in 1975 that adding people to a late project makes it later. Most organizations still act like throughput scales linearly with headcount. It doesn't, and it never has.

I lived this at a previous organization. Sixty engineers, and we spent more time coordinating than building. Standups about the standups. Slack channels for discussing what should go in other Slack channels. Engineers getting maybe three hours of actual deep work done per day, and two of those hours were spent context-switching between threads. The calendar was a war zone.

When I started my current engagement, I made a deliberate choice: stay small, stay sharp, invest the headcount savings into tooling and compensation. Fifteen people, no more. It's been the best engineering decision I've made in years.

What "AI Multiplier" Actually Means Day to Day

Here's what actually happens when a strong engineer sits down with Claude Code or Cursor in a well-configured environment: they stop being one person. They become something closer to a small team.

Not in the magical "AI writes all the code" sense. In a practical, measurable sense. An engineer who used to spend 40 minutes writing boilerplate for a new service endpoint now spends 5 minutes reviewing and adjusting generated boilerplate. An engineer who used to spend two hours researching an unfamiliar API now has a working prototype in 20 minutes and spends the remaining time on the edge cases that actually matter.

On my team specifically: we use Claude Code as the primary implementation companion. Not as a replacement for thinking, but as a replacement for typing. When one of my senior engineers is building a new data transformation layer, she describes the schema, the business rules, the error handling requirements. Claude Code generates the implementation. She reviews, adjusts, tests. What used to take a full day takes a couple of hours. Not because the thinking is faster — the thinking is the same — but because the mechanical translation of thought into code is nearly instantaneous.

We've also built three internal tools on top of LLM APIs: a code review assistant that pre-screens PRs for common issues before human review, a documentation generator that keeps our API docs in sync with implementation, and a test scenario generator that produces edge case tests from specification documents. Each took less than a week to build. Each saves meaningful hours per week across the team.

Real Projects, Real Numbers

A client needed a real-time data pipeline processing a couple million events per day across 14 data sources — transformations, quality checks, alerting, and a monitoring dashboard. Their internal team estimated three months with eight engineers. We assigned three engineers and delivered in three weeks.

The AI multiplier was most visible in the transformation layer. We had 47 distinct transformation rules to write. Doing that by hand would have been weeks of work. One engineer generated and validated all 47 in two days with Claude Code. The rest of the time went to architecture, hardening, and the dashboard.

Another engagement: a unified API layer sitting in front of six legacy systems, with authentication, rate limiting, request transformation, response normalization, and comprehensive logging. Traditional estimate: eight engineers, four months. Our team: two engineers, six weeks. The key insight was that API integration work is heavily pattern-based — once you establish the pattern for one integration, AI tooling can replicate it across the others with minimal human intervention. The two engineers spent most of their time on the genuinely hard parts: understanding the quirks of each legacy system, designing the error handling strategy, building monitoring. The boilerplate was AI-assisted.

Why Small Is Actually an Advantage

Most people hear "15 engineers" and think constraint. I think advantage.

When I need to make an architectural call, I talk to two or three people. Not a committee. Not an architecture review board that meets biweekly. The decision cycle on my team is measured in hours. I've been in organizations where it was measured in weeks.

Every engineer on my team understands the full system. Not just their slice. When someone is out sick, we don't have a crisis. Any engineer can pick up any piece of work. Try that with a 60-person team working on the same product.

Each of my engineers owns more than they would on a larger team. That sounds like a burden. It's actually what keeps people engaged. Ownership creates quality. When you're responsible for the full lifecycle of a service — from design through deployment through 3 AM pages — you build it differently than when you're responsible for one layer of someone else's stack.

Hiring: The Part That Actually Changed

I don't test candidates on syntax anymore. I don't give them puzzles designed to see if they can write binary search without looking it up. If my engineers use Claude Code to write code daily, testing candidates without it is testing an irrelevant skill.

We give candidates a real problem from a recent project, anonymized, and ask them to design a solution. Then we give them access to Claude Code and ask them to implement a piece of it. We're watching their judgment, not their typing speed. Do they accept the first output or iterate? Do they test edge cases? Do they catch it when the model makes a plausible-sounding but wrong assumption? That last one tells you a lot about a person.

We also stopped hiring specialists. We need T-shaped people — someone who goes deep in one or two areas but can contribute meaningfully across the stack. Our best engineer is a distributed systems specialist who can write decent React when needed. Our frontend lead has enough infrastructure knowledge to debug a Kubernetes issue without calling for backup. AI tooling makes the T-shape easier to achieve because it provides a competence floor in unfamiliar domains. A backend engineer who's never touched React can navigate a React codebase much faster with Claude Code than they could have two years ago.

What I look for in interviews now: learning speed, not knowledge stock. The half-life of technical knowledge is shrinking. AI tools accelerate learning, but only for people who are already good at learning. If someone needs a structured curriculum and a patient mentor to pick up something new, this team will feel overwhelming. If they learn by diving in, breaking things, and iterating, they'll love it.

The Bus Factor Question

The most common objection I hear: "If two people leave a 15-person team, you're in trouble." It's a fair concern and I've thought about it a lot.

The counterintuitive finding is that AI tooling actually helps with this. In a traditional team, knowledge lives in people's heads. When someone leaves, that knowledge walks out. On an AI-augmented team, knowledge lives in the code, in documentation that AI tools help keep current, and in the codebase itself — which a new team member can use Claude Code to explore and understand.

When we onboarded two engineers last quarter, their ramp-up time was roughly half what I'd historically expect for a codebase of this complexity. They used Claude Code to explore the codebase, ask questions about architectural decisions, understand the reasoning behind implementation choices. Within two weeks, they were making meaningful contributions. Two weeks. I've seen onboarding take eight weeks in other roles for similar complexity.

We also maintain a lightweight decisions log — a document where we record significant technical decisions and the reasoning behind them. Not a heavy process, just a habit. AI tools help keep it updated. Institutional knowledge captured, not just carried around in one person's head.

What Doesn't Scale Down

I want to be honest about where small teams struggle.

Coverage. Fifteen people in roughly one time zone means you don't have 24/7 engineering coverage. We handle it with good alerting, runbooks, and on-call rotations. But if a client genuinely needs engineers available across three time zones, that's a real constraint.

Parallel workstreams. There's a ceiling on how many independent projects we can run simultaneously. We typically run three or four major engagements. If a client needs eight parallel workstreams, we can't staff them all.

Sustained high load is genuinely a risk. A small team running at high velocity can burn out. I watch for it constantly. We build in recovery time between intense projects. But the reality is that a team this productive attracts more work than it can handle, and saying no to interesting projects is a discipline I'm still learning.

The Part That Actually Matters

I've been in engineering long enough to be skeptical of claims about productivity multipliers. So let me try to say this carefully: what changed isn't that AI makes engineers obsolete or that code writes itself. What changed is that the mechanical parts of engineering — boilerplate, documentation, test scaffolding, API integration patterns — now cost almost nothing. Which means engineer time can go almost entirely to the parts that actually require human judgment: understanding the problem deeply, making architectural decisions that will hold up, building things that are maintainable by the next person who touches them.

That's a better use of smart people than having them copy-paste CRUD operations.

The engineers who'll thrive in this environment are the ones who were already good engineers and who see the tools as amplifiers for their judgment. The organizations that'll thrive are the ones that keep teams small enough to stay coherent, pay those people well enough to attract genuine talent, and get out of their way.

I have fifteen engineers. Most of them have been approached by larger organizations in the past year. Most of them have stayed. When I ask why, the most common answer is some version of: "I own more here. I can see what I built. It matters."

That's harder to manufacture at 200 people than it is at 15. And I think, for a lot of engineers, it's what they actually want.

Updated January 21, 2026