Tech Bottlenecks Killing Your Team's Velocity (And How to Fix Them Without AI)

Productivity in software engineering is a very contentious topic.

Especially with AI being such a big deal in recent years. Companies rush towards whatever AI tool they can with the goal of increasing their developers’ productivity.

But here’s the thing: AI tools can help, but they won’t fix fundamental bottlenecks in your delivery system. You can give developers the best AI coding assistant in the world, but if your deployment process takes 4 hours and requires manual steps, you’re still going to be slow.

One thing is certain, though, and I think we can agree on: reducing cycle time (or as we’ve been calling this so far-feedback loops) is crucial.

Let’s look at common bottlenecks that occur in software teams that destroy productivity, and more importantly, how to fix them.

Understanding Cycle Time

Before we dive into bottlenecks, let’s clarify what we mean by cycle time.

Cycle time is the time it takes from when work starts until it’s delivered to customers. This includes:

Development time
Code review time
Testing time
Deployment time
Any waiting time in between

The shorter your cycle time, the faster you can learn and adapt. Long cycle times mean:

Slower feedback from customers
More work in progress
Higher risk of changes conflicting
More context switching
Lower team morale

Bottleneck #1: Too Much Work in Progress

I know… it sounds weird to say. We want our developers to be productive, so we measure team velocity, estimate points, and try to fit as many as we can for the sprint.

Very often stakeholders push for their request to be at the top of the priority list. If developers push back, they are seen as lazy.

Leadership wants to do more, build more, deliver more features, etc.

The Capacity Illusion

But what happens when you fill up team capacity with tickets and there’s a production issue? Or a new market opportunity you need to work on that would take away from an initiative you’ve been building for two months now?

Work in progress increases because you have to deal with whatever thing just became the priority. This leads to:

More context switching: Developers jump between tasks
More delays: Nothing gets finished quickly
Longer lead time: Features take forever to complete
Higher defect rate: Rushed work has more bugs
Everyone is burnt out: Constant pressure and switching

The Estimation Problem

I haven’t even touched on how a 5-point story can multiply in size to 13 because you didn’t anticipate you’ll need to touch an ancient part of the codebase that nobody knows about anymore.

Here’s the truth: software engineering is not a predictable or deterministic activity. Yet we try to treat it as such.

The Solution: Limit Work in Progress

I won’t advise you drop story point estimates straight away-I recognize it’s a mental leap that seems too daunting or difficult initially. At the very least, you could use ranges to estimate work and not use points as a metric of productivity. Humans are notoriously bad at estimates, so by having an upper bound, you could at least have some leeway.

What really leads to productive delivery is ruthless prioritization and focus by reducing work in progress.

How to Limit WIP

Set explicit WIP limits: No more than X items in progress at once
Finish before starting: Don’t start new work until current work is done
Prioritize ruthlessly: Say no to low-priority work
Batch similar work: Group related tasks together
Visualize work: Use a Kanban board to see WIP

The Benefits

When you limit WIP:

Faster delivery: Work flows through the system faster
Less context switching: Developers focus on fewer things
Better quality: More time to do things right
Less stress: Clear priorities, less juggling
More predictable: Easier to estimate when things will be done

Bottleneck #2: Software Quality

Another very contentious topic.

The Traditional Flow

One of the most common ways of working is something like:

Create a feature branch
Code for a few days
Raise a PR
Wait a few days for review
Go to a dev environment
Staging environment
Production

If a change has introduced a bug/regression, you go back to the start-this is the feedback loop at the code level.

Think about how long it takes for a new change or bug fix to flow through your delivery system.

The Pipeline Problem

A common pitfall: slow builds/pipelines → people start avoiding using them at all → more bugs slip in or get caught at later stages in the delivery loop.

Some organizations add a manual QA step to try to resolve this, which ultimately leads to more slow-down.

The Firefighting Spiral

The slow-downs in this loop can be made even worse if you combine it with the issues from the previous section. You get a recipe for disaster where constant firefighting is the norm, and it becomes harder to deliver value for customers.

What Is Software Quality?

And this is what I ultimately define as software quality: delivering customer value now and in the future with as little change as possible. This means that the code doesn’t need to be rewritten every time a new feature comes in.

Quality isn’t about perfect code-it’s about code that:

Works correctly
Is modular and easy to change
Is well-tested
Is maintainable
Delivers value

The Quality Feedback Loop

The goal here is again to shorten the feedback loops we outlined above.

The faster you can get feedback on code quality, the faster you can fix issues. The longer feedback takes, the more expensive fixes become.

Measuring What Matters: DORA Metrics

The first step is to measure what matters without letting metrics become a goal or measuring stick. When they do, people start finding ways to game the system so they can make the numbers work.

A great starting point is using DORA metrics (DevOps Research and Assessment). These four metrics, developed by Google’s research team, uncover which parts of your delivery system need improvement.

1. Lead Time for Changes

How long from first commit to production? This is your overall feedback loop.

Why it matters: Long lead times mean slow feedback. You can’t learn quickly if it takes weeks to get changes to customers.

How to improve: - Switch from async to sync code reviews: One team I worked with cut lead time by 40% just by doing this-no more PRs sitting for days waiting for review. Instead of async PR reviews, have dedicated review sessions where reviewers are available immediately. - Automate testing: Catch issues earlier in the pipeline - Improve deployment frequency: Deploy more often, deploy smaller changes - Reduce batch size: Smaller changes = faster feedback

Quick win: Implement synchronous code review sessions. Set aside specific times when reviewers are available, and developers know they can get immediate feedback.

2. Deployment Frequency

How often do you deploy? This indicates confidence in your releases.

Why it matters: Frequent deployments mean: - Smaller changes (easier to review and test) - Faster feedback loops - Less risk per deployment - More practice (teams get better at deploying)

How to improve: - Automate testing: If you have a lengthy manual QA step blocking deployments, that’s your bottleneck. Automating testing and environment promotion is key here. - Improve confidence: Better testing and monitoring = more confidence = more frequent deployments - Reduce deployment risk: Feature flags, canary deployments, blue-green deployments - Make deployments routine: The more you deploy, the easier it gets

Quick win: Identify what’s blocking frequent deployments. Is it manual QA? Slow pipelines? Fear of breaking things? Address the biggest blocker first.

3. Mean Time to Recovery (MTTR)

How fast can you restore service when something breaks? Teams that recover quickly can deploy more confidently.

Why it matters: If you can recover quickly, you can deploy more often. If recovery is slow and painful, you’ll deploy less often and be more cautious.

How to improve: - Better monitoring: Know when something breaks immediately - Automated rollbacks: Can you roll back with one click? - Runbooks: Document common issues and how to fix them - Practice: Regular chaos engineering or incident drills - Post-mortems: Learn from incidents to prevent them

Quick win: Set up automated rollbacks. If a deployment causes issues, you should be able to roll back immediately without manual steps. A simple way is to have Docker image tags for every release that can be easily reverted to a previous version.

4. Change Failure Rate

What percentage of deployments cause issues? High failure rates mean you’re catching problems too late in the loop.

Why it matters: High failure rates mean: - You’re not catching issues early enough - Deployments are risky - You’ll deploy less often - Team confidence decreases

How to improve: - Better testing: Catch issues before production - Feature flags: Deploy code without enabling features - Canary deployments: Test with a small percentage of traffic - Better monitoring: Catch issues quickly - Post-mortems: Learn from failures

Quick win: Add automated tests that catch common issues. Even basic smoke tests can catch many problems before they reach production.

Improving These Metrics

Improving these metrics leads to better workflow for developers and more value delivered to customers. Start by measuring where you are now-you might be surprised.

The Measurement Trap

But be careful: don’t make metrics into goals. When metrics become goals, people optimize for the metric, not for the outcome.

For example, if you make “deployment frequency” a goal, teams might deploy meaningless changes just to hit the number. Instead, focus on the outcomes: faster feedback, better quality, more value.

Start Small

You don’t need to fix everything at once. Start with one metric:

Measure: Where are you now?
Identify: What’s the biggest bottleneck?
Fix: Address that bottleneck
Measure: Did it improve?
Repeat: Move to the next bottleneck

Common Quick Wins

Here are some quick wins that can improve multiple metrics:

Automated Testing: - Reduces change failure rate - Increases deployment frequency - Decreases lead time

Synchronous Code Reviews: - Decreases lead time significantly - Improves code quality - Reduces change failure rate

Feature Flags: - Increases deployment frequency - Reduces change failure rate - Enables faster rollbacks

Better Monitoring: - Decreases mean time to recovery - Reduces change failure rate - Increases deployment confidence

The AI Question

You might be wondering: what about AI tools? Can’t they help with productivity?

Yes, but…

AI coding assistants can help with: - Writing boilerplate code - Generating tests - Explaining code - Refactoring suggestions

But they won’t fix: - Slow deployment processes - Poor code review practices - Lack of testing - Too much work in progress - Long feedback loops - Layers of hierarchy required for a decision

AI can make individual developers faster, but it won’t fix system-level bottlenecks.

Focus on fixing the bottlenecks first. Then AI tools can amplify your improvements.

The Quality vs. Speed Trade-Off

One common misconception is that quality and speed are opposites. You can either go fast or do quality work, but not both.

This is false.

High-quality processes actually enable speed:

Good tests: Catch issues early, deploy with confidence
Code reviews: Prevent bugs, share knowledge
Automation: Remove manual steps, reduce errors
Monitoring: Catch issues quickly, recover faster

The teams that go fastest are the ones with the best quality practices. And it’s also much more enjoyable for developers to work in an environment where they are enabled to do good work as opposed to being held down by processes.

Creating a Culture of Quality

Improving these metrics isn’t just about tools and processes-it’s about culture.

Psychological Safety

Teams need to feel safe to: - Deploy frequently (without fear of breaking things) - Experiment (without fear of failure) - Learn from mistakes (without blame)

Continuous Improvement

Make improvement part of your regular process: - Regular retrospectives - Experimentation - Learning from failures - Celebrating improvements

Focus on Outcomes

Measure outcomes, not just outputs: - Are customers getting value? - Are we learning faster? - Are we improving? - Are developers happier?

Conclusion

Productivity in software engineering isn’t about working harder or using the latest AI tools. It’s about identifying and fixing bottlenecks in your delivery system.

The four DORA metrics-lead time, deployment frequency, mean time to recovery, and change failure rate-give you a framework for understanding where your bottlenecks are.

Common bottlenecks include: - Too much work in progress - Slow code review processes - Manual testing and deployment steps - Poor monitoring and recovery processes

The good news is that these are all fixable. You don’t need AI or expensive tools-you need to:

Measure where you are
Identify the biggest bottleneck
Fix it with process improvements
Repeat

Start with one metric, make one improvement, and measure the impact. You’ll be surprised how much faster you can go when you remove the bottlenecks.

The best teams aren’t the ones with the most developers or the best AI tools-they’re the ones with the shortest feedback loops and the fewest bottlenecks.

If cycle time is creeping up in your organization, it’s time to identify where time is actually waiting and fix those bottlenecks. Your team’s velocity depends on it.

If you want a fast, objective view of what’s slowing delivery down in your organization, you can do my 2-minute Delivery Flow Assessment to get a personalized report of how your team operates and suggestions on how to improve.

Or if you’d like to a more personalized approach and 1-to-1 time with me let’s have a conversation - Book a Call here

It’s a more comprehensive analysis where we’ll map your value streams, identify bottlenecks, and outline how we can work together to improve your delivery system.