Why More Engineers Won't Fix Your Velocity Problem

Every CTO has had this conversation. The board asks why delivery is slower than expected. The instinct, almost every time, is the same: hire more engineers.

It makes intuitive sense; more engineers should mean more output. It's also a visible response; something you can point to in a board meeting as evidence that you're addressing the problem.

The same instinct often follows a fundraise. Fresh capital creates pressure to grow, and hiring is one of the easiest ways to show momentum, even when the underlying delivery constraints haven't changed.

The trouble is that delivery problems rarely come down to engineering capacity alone. More often, they're symptoms of something further upstream. Add people before you've solved that underlying problem, and you don't get more output; you get more expensive confusion.

The factory model doesn't apply here

The instinct to add people comes from a mental model many leaders absorb without really questioning. Building a product is treated like building a factory: more machines, more workers, more output. It's a clean, linear relationship.

Software development doesn't behave that way.

Fred Brooks described this problem more than fifty years ago in The Mythical Man-Month: adding people to a late or poorly defined project usually makes it later. Every new person increases the amount of coordination needed across the team. A five-person team has ten lines of communication to keep aligned; double the team to ten, and that jumps to forty-five. So instead of spending time shipping product, the team spends more time aligning context, explaining decisions, and reconciling different assumptions.

Software development also isn't deterministic in the way manufacturing is. Two engineers working from an unclear requirement rarely produce twice the output. More often, they produce two different interpretations of the same problem, and the team spends the next sprint untangling them.

That's also why raw delivery metrics can be misleading. They tell you how much code moves through the system, not whether it was the right work or whether it needed rebuilding later.

Across the organizations we've worked with, the same pattern appears repeatedly. The bottleneck is rarely engineering throughput or having too few hands on keyboards. It's usually decision quality: clarity around what should be built, ownership of who drives it forward, and how quickly good decisions get made.

A better way to find the real bottleneck

Before adding another engineer, run your delivery process through these four checkpoints to identify where work is actually slowing down.

This isn't a pitch for running delivery as a waterfall. Good teams run discovery and delivery in parallel, continuously refining requirements as they learn. But, before code gets written, it's crucial that someone creates enough clarity for engineering to progress with confidence.
‍

Checkpoint 1: Business requirements - Are you solving the right problem?

Every initiative should begin with a clear business objective tied to an outcome leadership actually cares about.

From there, those objectives need to be translated into high-level requirements. If requirements are vague, contradictory, or disconnected from the original goal, it means development will start from unstable foundations.

Just as important, those requirements need to be validated before they're built; through customer conversations, usage data, or evidence that customers are willing to pay. An unvalidated requirement is just an opinion with a deadline attached.
‍

Checkpoint 2: Product discovery, design, and scoping - Does engineering have enough clarity?

This is where a lot of scaling companies struggle.

Validated business goals still need translating into specifications engineers can build against. That means defining scope, sequencing work, and making the UX and design decisions that determine what "done" looks like.

Skip this step and two things can happen: engineers stall while waiting for direction, or they move ahead confidently on assumptions that later prove wrong. Either way, the result is rework.
‍

Checkpoint 3: Engineering execution - Does someone own delivery?

If requirements are clear and specifications are solid but work still isn't moving, the problem usually sits in ownership.

Is one person accountable for driving the work forward, or is responsibility diffused across a group that never quite agrees on who calls it?
‍

Checkpoint 4: Quality assurance and release - Can work reach production efficiently?

If work is well-specified and well-executed but keeps stalling before it ships, look at testing and release readiness.

That's usually a sign QA was bolted on at the end of the process instead of built into the workflow from the start, which creates bottlenecks at exactly the point where momentum should be highest.

Walking through these checkpoints tells you something a velocity chart never will: where the friction actually sits.

Sometimes the answer genuinely is: "we need another engineer." More often, though, it's a decision-making problem, an ownership problem, or a process problem further upstream. Sometimes, the process itself is the bottleneck; if specs sit in a queue for two weeks before anyone picks them up, or QA only begins after development finishes, adding engineers won't shorten the queue.

What twenty engineers taught us about ownership

A few months ago, one of our Series B clients had an urgent, high-stakes feature request land from a major customer. Revenue depended on it, the CEO was watching closely, and the instinct across the organization was to throw people at the problem.

So, a meeting was called. Roughly twenty people showed up, engineers included, all trying to figure out what to build from a research document that had just landed in their inbox.

But nobody in the room had defined the goal. There was no clear owner or agreed next step. Just twenty capable people waiting for direction that didn't exist.

One of our product leads stepped in. They canceled the meeting, clarified exactly what needed to happen (and in what order), and took ownership of the work end to end with a focused team of four. Within a week, that team had a plan the wider group could execute against, and the feature was shipped by the original deadline the twenty-person meeting had been trying to protect.

Nothing about the technical difficulty changed between those two meetings. What changed was that someone owned it.

That's the pattern we see repeatedly in high-growth teams. When pressure increases, the instinct is to add headcount, when what the moment really needs is a single accountable owner with a clear plan.

When hiring is the right call

That's not to say headcount is never the answer. There are plenty of legitimate reasons to grow a team. But it's important to be honest about which one applies.

Perhaps you're launching a new product line and genuinely need a dedicated team to get the job done. Or maybe the backlog is well scoped, priorities are clear, and everyone is already fully allocated. Those are real capacity needs, not a symptom of dysfunction.

A fundraise can justify it too. Series A and B rounds usually exist to fund new product initiatives, and growing into that valuation requires additional capacity. Hiring after a fundraise isn't the problem. Hiring before anyone's figured out what to build is.

Companies that hire a wave of engineers and figure out product direction later often end up with expensive people waiting on decisions that haven't been made yet. The right sequence is to first bring on the people who create product direction and scope, validate the proposed solution, then add engineering capacity where it's genuinely needed.

Hire for clarity first. Then hire to execute.

The role most companies underweight

If there's one hiring pattern worth paying attention to, it's this: companies tend to overvalue engineering capacity and undervalue the people who create clarity, whether that's product leads, business analysts, or engineers with strong product instincts operating beyond pure execution.

Marty Cagan's Product Trio model suggests a different approach: product, design, and engineering working together during discovery to shape the solution, rather than treating engineering as the final stop after a spec has been written. Teams that operate this way are less likely to build the wrong thing in the first place, which is far cheaper than fixing it later.

That imbalance (over-indexing on technical executors) shows up in organizational design too. Many product orgs invest heavily in engineering while underinvesting in the functions that frame problems at the start and validate outcomes at the end.

This reflects what Team Topologies, by Matthew Skelton and Manuel Pais, calls managing cognitive load. A stream-aligned team drowning in undifferentiated work does not need more headcount. More often, they need stronger support at the edges: around discovery, prioritization, and validation. The healthiest teams invest more heavily in discovery and validation than most, while trusting smaller, focused engineering groups to execute.

That isn't always an easy mindset to adopt for CTOs who came up as engineers and who value technical depth above all else. It's easier to see in practice than in theory.

We've watched a team with a dedicated product and QA layer working alongside engineers become the fastest-moving team inside an otherwise product-light organization, in a situation where the client hadn't even wanted that role on the team to begin with. Once the results became evident, that person became the most important hire on the team.

Why AI makes this problem more expensive

Early on, there was a widespread assumption that AI would make product managers and analysts less important. The opposite has happened.

As the mechanics of writing code become faster, the bottleneck shifts even further upstream toward knowing what to build and validating that it's right. Some of our own most complex projects are now weighted more heavily toward product and QA than engineering, precisely because that's where the constraint moved.

The spending data reinforces that point. Enterprises have poured an estimated $30 to $40 billion into generative AI pilots, yet MIT's NANDA initiative reported in 2025 that 95% of these produced no measurable return. The projects that succeeded had one thing in common: they were led by managers close to the actual work, not a centralized AI lab.

The same patterns played out in 2026. Amazon scrapped an internal AI usage leaderboard after employees optimized for token consumption rather than outcomes. Uber exhausted its whole year's AI budget within four months without a measurable increase in delivered projects. In both cases, more AI usage didn't translate into more value, because usage was being measured (and rewarded) instead of outcomes.

The lesson is the same as it is with hiring: AI is a multiplier, not a fix. It amplifies whatever already exists inside a team.

Give a strong, accountable person better tools and they become dramatically more effective. Give a disorganized team AI tools without fixing the underlying clarity problem, and you get the same bad decisions made faster, at a higher token bill. A team without ownership doesn't become efficient because it adopted AI. It becomes expensive.

That has real implications for how boards think about AI investment versus hiring. Before increasing either budget, figure out what you're actually short on: people, AI capability, or clarity about what should be built. Throwing more token spend at a team that hasn't solved the third problem produces the same disappointing outcome as throwing more headcount at it; it simply moves the cost to a different line on the P&L.

Reframing the conversation with your board

Part of why headcount remains the default answer is that it's a much easier conversation to have with a board than "our decision-making process is broken." There's no clean framework for that second conversation; no slide that summarizes it neatly. But, often, it's the conversation that needs to happen.

The shift starts with what you measure. Story points are relative and team-specific by design; rolling them into a single number for a board deck will effectively have you comparing invented units across teams that don't share a scale. Sprint velocity has the same limitation: it tells you how much work moved, not whether the business moved.

What matters are outcomes. The industry already has mature frameworks for this. DORA's four key metrics (deployment frequency, lead time, change failure rate, and time to restore service) measure the health of your delivery system. The SPACE framework, developed by Microsoft and GitHub researchers, complements that by measuring satisfaction, performance, activity, communication, and efficiency. Pair either of them with customer and commercial outcomes, and you will have a much stronger basis for deciding whether you need more people, a better process, or clearer priorities.

That changes the conversation with your board.

You also must be willing to push back. If, for example, a board member insists the company needs a mobile app, resist the urge to answer yes or no. Explain what problem it solves, where it sits in the roadmap, and what the trade-offs are. Boards respect CTOs who can hold that conversation. They lose confidence in the ones who can't.

The uncomfortable truth

If there's one uncomfortable truth every CTO eventually runs into, it's this: your delivery speed is a product of the system you've built.

It's shaped by your methodology, your team structure, and how decisions get made. Adding ten more engineers doesn't change those things; it just adds ten more people operating inside the same system.

Fixing that system is harder than hiring. There's no universal playbook because every organization accumulates its own bottlenecks, habits, and constraints over time.

That's why hiring is so often the default response. It's the easier answer to a much harder problem.

‍