How to turn around a slow software team

Is your software team slower than it should be? Several years ago (I'll leave the exact number out to protect my ego), I led software development at a software company. We had 21 developers in-house and 10 offshore on about a $3M budget, and the critical projects were running late. We got those projects back on time and on budget by looking at how work moved through the team, from the first request to release, and fixing the places where it got stuck.

I hear a version of the same problem now from owners and IT leaders, with one addition. The team has been told to use AI, and everyone expects that to make it faster. In my experience the fix is still the one we used then. Speed comes from how work flows through the team, and AI agents multiply whatever process they are dropped into. I've also come to think the bigger payoff is in how the work gets described. In an AI-native development process, where agents do much of the building inside a defined workflow, work starts as plain-language requests and specs and is judged by outcomes. That is how owners and non-technical people already think, so the team ends up working more like the rest of the business. Agents can then take on more of the process itself. Implemented well, I believe this goes well past the best processes we had before AI, on speed and on quality.

How much does AI speed up software development?

It depends on the process around it, and published results point in different directions. In a controlled experiment by GitHub and Microsoft researchers, developers using Copilot finished a small, self-contained programming task about 56 percent faster than developers without it (Peng et al., 2023). In a randomized trial by METR, experienced developers working in large codebases they knew well took 19 percent longer with AI tools, even though they believed the tools had sped them up (Becker et al., 2025a, 2025b). METR's follow-up suggests newer tools likely do better, though METR says its data can't show by how much (Becker et al., 2026). Google's DORA research on AI-assisted development describes AI as an amplifier of the strengths and problems a team already has (DORA, 2025).

I don't promise owners a number. A team told to use AI with nothing else changed gets a faster tool inside the same unclear priorities and manual releases. I made the general business version of this argument in AI makes bad process faster. My own experience moving projects to agent-driven work points the same way. Most of the effort went into writing good issues and specs and setting up review gates. The choice of model mattered less.

Signs the problem is process

When an owner tells me the team is not delivering, I look at how work reaches the developers and how it leaves them. A few signs come up often.

• Requests arrive from several directions, and nobody owns a single priority list.
• Work items are so large that nobody can say when one will be finished.
• Releases are events people dread, and testing happens when someone has time.
• One or two people are the only ones who understand the core system, so a lot of work waits on them.

What follows is a composite, drawn from patterns rather than any one company. Picture a distributor whose order system was built in-house years ago and has been patched ever since. Sales asks for a pricing change and the owner asks for a customer portal, and each request goes straight to whichever developer that person happens to know best. Everything is urgent, so most of it sits half done. Releases happen late on a Friday, and Monday goes to fixing what broke. The developers work hard, and from the owner's chair the team still looks slow.

How to measure developer productivity without jargon

You don't need a dashboard product to start. A few plain measures will do.

• How long a request takes to go from asked for to live
• How often the team releases
• How often a release breaks something or needs a follow-up fix
• How much work is waiting, and where it waits (a decision, development, testing, or release)
• How much of the team's time goes to new features versus bug fixes, tech debt and general upkeep

Most of these line up with the delivery measures Google's DORA team publishes, and DORA's research has found that speed and stability tend to improve together (Harvey, 2026). DORA also warns against turning a measure into a target. The measures are there to show where work waits.

At that software company, measuring delivery came first. Before changing anything else, we needed an agreed view of which projects were late and where they were stuck. Once the team and leadership look at the same picture, the conversation tends to move from whose fault a delay is to what to fix next. Setting up measures like these is part of our IT team transformation work.

The fix order

I fix things in order, because each step depends on the one before it.

1. Start by making the work visible. Put every request in one queue with a clear owner, and break the work into small, well-defined pieces.
2. Then add a real quality gate, so every change passes a review or test step before it ships. Poor quality slows a project down too, because end users won't sign off on work they don't trust.
3. Automate the build and the deployment, so a release no longer depends on someone repeating manual steps correctly every time.
4. Bring in agents last, once there is a process for them to work inside.

Teams that jump straight to step four usually end up with more code and the same delays. The quality and release practices in steps two and three are also covered by our IT delivery work.

Using AI agents on legacy code

What I aim for now is a workflow where the owner states what they want, and the work carries through to production with checks along the way. Each change follows the same path.

• An issue with acceptance criteria, written in plain language
• A written spec and plan before any code
• Agents write the tests first, then the change
• Separate agents review the code and its security, and automated checks run on every change
• The change lands in staging, and after a person approves it, the same tested build is promoted to production

People still decide what goes into the spec, and a person decides whether to accept any risk a reviewer flags.

BaronTek's own website runs this way, and security has its own loop. Once a week an agent runs a low-impact penetration test and vulnerability scan, and that job has no permission to change code. A daily agent checks for new security issues and fixes problems through the same workflow. A high-priority fix can go straight to production once it has passed independent review and the full set of checks, and that exact build has passed a smoke test on staging. Everything else waits in staging until I approve that specific build, and each approval works only once.

Next, I'll be using the same workflow with a company president on a rewrite of their operating platform. Agents will write and test the code, and releases will be approved from staging. For owners with older custom code, this is what our custom software work looks like today.

How a non-developer leader can tell it is working

You shouldn't need to read code to tell. Over a few months the measures above should move in the right direction. Requests reach production sooner and fewer releases need a follow-up fix. Releases get smaller and more frequent, until a deployment stops being an event. You should also be able to see the queue yourself and approve releases from staging instead of hearing about them afterward.

For the composite distributor above, success would look ordinary. The pricing change ships midweek after the owner has looked at it on staging, and Monday is a normal workday.

When outside help makes sense

Outside help makes sense when the team is capable but nobody has time to change how work flows while still delivering. It also helps when the codebase is old enough that agents need tests and a staging environment in place before they can work on it safely.

If you own legacy custom code, start with custom software and integrations. If you're an IT leader being asked to speed up the team and bring in AI, see IT team transformation. Either way, a short note on what feels slow is enough to start.

Sources

• Becker, J., Rush, N., Barnes, B., & Rein, D. (2025a, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Becker, J., Rush, N., Barnes, E., & Rein, D. (2025b). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv. https://arxiv.org/abs/2507.09089
• Becker, J., Rush, N., Cunningham, T., Rein, D., & Mahamud, K. (2026, February 24). We are changing our developer productivity experiment design. METR. https://metr.org/blog/2026-02-24-uplift-update/
• DORA. (2025). State of AI-assisted software development 2025. Google Cloud. https://dora.dev/research/2025/dora-report/
• Harvey, N. (2026, January 5). DORA's software delivery performance metrics. DORA. https://dora.dev/guides/dora-metrics-four-keys/
• Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv. https://arxiv.org/abs/2302.06590