Short answer: When delivery slows, hiring is the most obvious fix and often the wrong first one. Map how work moves from idea to production, find the stage where it waits longest, and fix that constraint first. Hire once you can show the problem is capacity and not architecture, process, or unclear ownership.
Imagine a SaaS team that has doubled its engineering headcount in a year. The roadmap is documented, sprints run on schedule, and everyone looks busy. Yet a feature that used to take two weeks now takes four, pull requests wait days for review, and the product manager keeps asking when the next release will be ready.
The instinct is to hire. More people should mean more output, especially when customers are asking for more.
I’ve seen that instinct cost companies a lot of money, so I’ll say it plainly: if your engineering velocity is falling, the cause is often somewhere other than headcount. Adding people to a system that can’t move work efficiently tends to add coordination overhead, not speed.
Full disclosure: I run Enlight Lab, and fractional CTO support is one of the things we sell. I’d still rather you diagnose the problem yourself first, so this article gives you the method I use. You can run most of it with a spreadsheet and a few honest conversations.
What “engineering velocity” actually means
People use three terms interchangeably, and they measure different things.
- Sprint velocity is the amount of estimated work a team finishes in a sprint, usually in story points. It’s useful for planning inside one team. It isn’t a measure of business value.
- Developer productivity is about how effectively individual engineers contribute: coding, collaboration, problem solving and quality.
- Engineering velocity is the broader question of how quickly and reliably the whole organization turns a clear requirement into working software in production.
A team can finish more story points and deliver less value. It can merge hundreds of lines of code and make no progress toward a release customers can use. That’s why I never treat velocity as a single number. The useful question is this: how long does it take to turn a well-defined requirement into a reliable production release, and what stops us from doing that consistently?
Why adding developers can backfire
Fred Brooks made the classic version of this argument in The Mythical Man-Month: adding people to a late software project tends to make it later. The details differ in a modern SaaS company, but the mechanism still holds.
- More coordination. Every new engineer adds communication paths and planning overhead.
- More work in progress. If too many tasks are already open, extra people create more unfinished work, not more releases.
- More onboarding. New hires need your most experienced engineers’ time, which slows the people you were counting on.
- More strain on the architecture. If the codebase is hard to change safely, more contributors means more conflicts.
None of this means hiring is a mistake. It means hiring should solve a capacity problem you have actually diagnosed.
Six reasons velocity falls as a SaaS company grows
Slowdowns rarely appear overnight. A process that worked for four engineers strains at fifteen, and a product built for the first hundred customers struggles with the next thousand. These are the causes I see most often, and what I look for in each.
1. Maintenance is eating the roadmap
Early products trade polish for speed, which is usually right. The trouble starts when temporary shortcuts harden into the architecture: tightly coupled services, duplicated business logic, thin test coverage and undocumented dependencies. A small change then touches several places, and engineers spend their time understanding, testing and repairing instead of building.
What I look for: the share of time going to bugs, incidents and rework versus new features, and the parts of the code where small changes keep causing surprises. If maintenance is taking a growing share of capacity, new hires will mostly inherit that complexity.
2. Work waits between stages
A developer can finish a feature quickly and still take two weeks to reach customers, because it waits for code review, QA, a security check, a deployment window or a decision from another team. Nobody looks overloaded, because the work is simply sitting still.
What I look for: how long work spends in each stage, and where it waits longest. Often it’s review or release coordination, not coding.
3. Requirements change mid-build
Developers start a feature, hit a missing decision, pause, resume, and sometimes learn at the end that expected behavior has changed. Each interruption means context switching and rework, and it gets worse when founders change priorities without counting the cost of the work already in flight.
What I look for: how often requirements change after development starts, how much finished work is reopened, and how often engineers switch between competing priorities. Clear acceptance criteria and a named owner before work begins fix a surprising amount of this.
4. The architecture prevents independent work
In a tightly coupled system, unrelated features can require edits to the same components. Shared databases, unclear service boundaries and fragile APIs make parallel work risky. More engineers means more people waiting on the same few files.
This does not automatically mean you need microservices or a rewrite. Those carry their own complexity. Often a targeted refactor, clearer module boundaries and better tests remove the constraint at a fraction of the cost.
What I look for: recurring merge conflicts, shared components that block releases, slow test suites, and integrations that need several engineers to coordinate.
5. Nobody owns the system as a whole
You can have capable engineers and a good product manager and still lack technical leadership. Who decides which technical debt matters most? Who settles architecture disagreements? Who is accountable when releases keep slipping?
When those answers are unclear, decisions take longer and problems stay open. Founders end up making technical calls they aren’t equipped to judge, and senior engineers spend their time refereeing instead of improving the system.
What I look for: how architecture decisions get made, who owns delivery improvements, and whether the roadmap accounts for system health as well as features.
6. AI features add their own drag
If you ship AI features, there are extra ways to slow down. Model behavior changes, evaluation is manual or missing, a provider outage becomes your outage, and agent loops or runaway costs cause incidents that pull people off the roadmap.
What I look for: whether the team can test AI quality before every change, whether runs have step, time and spend limits, and whether failures reach you before they reach customers. If those are missing, expect AI work to generate unplanned firefighting.
How to find the real bottleneck: five steps
A good diagnosis combines delivery data, observation of the workflow and conversations with the people doing the work. No dashboard will explain everything.
Step 1: Map the path from idea to production
Write down how a typical feature moves through your organization. A simple version looks like this:
Idea → Requirements → Development → Code review → Testing → Deployment → Production
Yours may also include design, security review, data migration or an external vendor. For each stage, ask three questions:
- How long does active work take here?
- How long does work wait before someone picks it up?
- What sends work back to an earlier stage?
The gap between active time and waiting time is where most of the surprise lives. Map five or six recent features, and include delayed ones and failed releases, not just the easy wins.
Step 2: Measure flow, not busyness
The DORA research programme popularized four measures of delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. They’re a good starting set because they describe the system, not individuals. I’d add three more that are easy to track and very revealing. Check the current DORA material for its exact definitions, since the programme has refined them over time.
| Measure | What it tells you | Healthy (my rule of thumb) | Warning sign |
|---|---|---|---|
| Deployment frequency | How often you release | Weekly or more often | Monthly or less; releases feel like events |
| Lead time for changes | Time from code written to code live | Days | Weeks, mostly spent waiting |
| Change failure rate | Share of releases that cause a problem | Low, and falling | Roughly one release in three or worse |
| Time to restore service | How long recovery takes | Hours | Days, or “it depends who’s around” |
| Cycle time (my addition) | Time from work starting to finishing | Steady and predictable | Tasks stay open far longer than expected |
| Work in progress (my addition) | Tasks open at the same time | Few enough to finish | Many open, few finished |
| Rework (my addition) | Work repeated after defects or unclear requirements | Falling | The team keeps revisiting “done” work |
The “healthy” column is my rule of thumb for early-stage SaaS, not an industry benchmark. Use these numbers to understand your system, not to rank developers. A long cycle time could mean complex work, slow decisions, poor task breakdown or an overloaded review process. The number alone doesn’t tell you which.
Step 3: Find the stage with the largest recurring delay
Suppose you review your last twenty completed features and find this average timeline. The numbers are invented for illustration.
| Stage | Average time |
|---|---|
| Requirements and clarification | 2 days |
| Implementation | 4 days |
| Code review | 3 days |
| Testing and fixes | 4 days |
| Deployment and release coordination | 2 days |
That’s 15 days from start to finish, and only 4 of them are implementation. Telling developers to code faster would barely move the total. The interesting questions are why testing takes as long as building, why review takes three days, and why deployment needs two.
Are defects appearing because acceptance criteria were unclear? Is the test suite unreliable? Are reviewers overloaded? Are there manual deployment steps that could be automated? Each answer calls for a different fix. Fix the constraint that limits the whole process before polishing a stage that already works reasonably well.
Step 4: Talk to the people doing the work
Numbers show patterns. Conversations explain them. Ask engineers:
- What repeatedly stops you from finishing work?
- Which parts of the codebase are risky to change?
- What would you fix first if you had a week with no feature deadlines?
Ask product and business stakeholders how often priorities change after work starts, where requirements stay unclear, and whether release dates come from delivery data or from optimism.
Look for answers that repeat. If three engineers independently name the same fragile service, believe them. And make it clear the data is for improving the system, because people stop reporting real problems if they think someone will be blamed.
Step 5: Separate capacity problems from system problems
You have a capacity problem when the backlog is clear and prioritized, requirements are defined, work flows without long waits, and there still isn’t enough engineering time to meet demand.
You have a system problem when you have enough people but work is held up by unstable architecture, unclear priorities, repeated defects, manual releases or decisions nobody owns.
Many companies have both. The point is to know which one to fix first, and how much extra capacity would genuinely help.
Hire, or fix the process?
Use what you observed to choose the response.
| What you see | Where to look | Likely response |
|---|---|---|
| Developers wait for requirements | Product discovery and decisions | Clarify requirements and name a decision owner |
| Pull requests sit for days | Review capacity and ownership | Set review expectations; keep changes small |
| Small changes break unrelated features | Architecture and tests | Fix fragile components; add automated tests |
| Releases need heavy manual coordination | Deployment | Automate the pipeline and rollback |
| Many tasks open, few finished | Prioritization and work in progress | Limit parallel work; finish what’s started |
| Process is healthy, demand still exceeds capacity | Capacity | Hire for specific skills |
| Technical decisions keep stalling | Technical leadership | Clarify ownership or add experienced oversight |
Treat this as a starting point. Slow reviews, for example, can come from too few reviewers, unclear code ownership, oversized pull requests or risky architecture. Find the cause before you choose the cure.
A lesson from a different kind of slowdown
Not every velocity problem looks like slow delivery. I was once brought in when a client’s production AI agent platform went down, with agents stuck in loops that never ended. The pressure in the room was to rebuild.
The right answer was to stabilize. A root-cause fix in the runtime, plus hardening and proper credential handling, kept the customers and the codebase. A rebuild would have paused feature work, carried its own risks and probably taken longer than planned.
That was an outage, not a slow roadmap, but the lesson is the same. The expensive reaction (rebuild everything, hire more people) is tempting when you’re under pressure. A diagnosis is cheaper, and it usually points to something smaller.
A 30-day plan to find and fix the constraint.
You don’t need to reorganize engineering to start. Thirty focused days can show you where the biggest drag is.
Week 1, baseline. Review recently completed features, delayed releases, incidents and unfinished work. Capture lead time, cycle time, deployment frequency and change failures where your data allows. Interview engineers and product stakeholders. Result: a clear picture of where delivery slows down, with examples.
Week 2, find the main constraint. Group problems into categories: architecture, review, testing, requirements, deployment, prioritization and decision-making. Look for patterns, and estimate the business impact of each. A release bottleneck that threatens a customer commitment outranks a minor tooling annoyance. Result: a ranked list of bottlenecks with evidence.
Week 3, run one targeted fix. Pick the change that addresses the biggest constraint. Examples: break large pull requests into smaller ones, add automated tests around a hot spot, cap work in progress, write acceptance criteria before work starts, automate one manual deployment step, or name an owner for architecture decisions. Change one thing at a time so you can tell what helped. Result: one implemented improvement with a stated measure of success.
Week 4, review and decide. Compare against your baseline. Did waiting time fall? Did changes reach production sooner? Did rework drop and reliability hold? Allow for differences in task size and outside dependencies, since a short window shows signals, not trends. Result: an evidence-based plan for the next 60 to 90 days.
I won’t promise a percentage improvement in thirty days, and you should be wary of anyone who does. The aim is to replace assumptions with evidence.
When a fractional CTO makes sense
Some bottlenecks yield to a better process. Others need broader technical judgment, for example when:
- architecture decisions are unresolved and keep stalling projects,
- technical debt has piled up with no way to prioritize it,
- the product roadmap and engineering capacity have drifted apart, or
- nobody clearly owns delivery risk.
A fractional CTO gives a growing company senior technical direction without a full-time executive hire. In practice that means assessing the architecture, prioritizing debt by business impact, setting up a few useful metrics, aligning product priorities with capacity, and helping you decide whether to refactor, automate, modernize or hire. The value is judgment that links engineering decisions to business priorities, not just another manager.
It isn’t the right answer for every team. If your process is healthy and you simply need more hands, hiring is the better move.
Your next step
If you want to go deeper on your own, download The SaaS Scaling Playbook. It includes a 50-point scorecard, a method for sorting issues into fix now, 90 days or leave alone, and a rebuild test, so you can decide between keeping on shipping, refactoring, stabilizing or rebuilding.
If you’d rather talk it through, book a 30-minute conversation. Bring your last few releases and your delivery numbers, and I’ll tell you where I’d look first. You can also read our case studies to see the kind of work we do.
Frequently asked questions
What causes engineering velocity to drop?
Usually a mix of technical debt, tightly coupled architecture, unclear or shifting requirements, slow code review, manual releases, recurring defects and weak technical ownership. Which one dominates varies by company, so look at delivery data and workflow delays before choosing a fix.
How do you measure engineering velocity?
Use several measures together: lead time for changes, cycle time, deployment frequency, change failure rate, time to restore service, work in progress and rework. Story points help a team plan within a consistent process, but they don’t measure customer value or overall productivity.
Does hiring more developers increase velocity?
It can, when the real constraint is capacity. If work is stuck in unclear requirements, slow reviews, fragile architecture or manual deployment, extra developers often raise coordination costs without fixing the cause.
What’s the difference between engineering velocity and developer productivity?
Developer productivity looks at how effectively engineers do their work. Engineering velocity looks at the whole system that turns that work into reliable software. A very productive developer can still be stuck waiting for decisions, reviews or approvals.
Which metrics should an early-stage SaaS team track first?
Start with lead time for changes, deployment frequency, change failure rate and time to restore service. Add cycle time, work in progress and rework if you can do so without creating a reporting burden.
How long does it take to improve engineering velocity?
It depends on the constraint. Clearer requirements or a better review routine can show results within weeks. Architecture changes, test automation or modernization often take months. Set a baseline, change one thing at a time and watch both speed and reliability.
How can a fractional CTO help?
By finding architectural and organizational constraints, clarifying technical ownership, prioritizing debt, improving delivery practices and aligning engineering work with business goals, without requiring a full-time CTO hire.
The bottom line
When velocity falls, hiring is the fastest-feeling answer and sometimes the right one. But without a diagnosis, it can raise your costs and leave the real problem untouched.
Start by looking at how work moves to production. Measure where time goes, talk to the people doing the work, and decide whether you have a capacity problem or a system problem. Then fix the biggest constraint before you make the next big investment.
Enlight Lab is a software engineering and technical leadership partner for founders and technology leaders. We help teams assess architecture and delivery constraints, prioritize improvements, and ship reliably.
