Improving Developer Productivity: What Slows Teams Down

Many organizations treat individual developer performance as a measure of engineering productivity, assuming that more code, commits, and completed tickets lead to better delivery results. 

AI has exposed the flaw in that thinking. Higher output doesn’t automatically translate into faster delivery or better outcomes. AI can accelerate coding, but it can’t fix operational bottlenecks, like work sitting in review queues, testing, and release pipelines, or waiting on dependencies. Engineering leaders must understand how work flows through the SDLC, where it gets stuck, and how to optimize the system as a whole. 

In this article, we’ll explore the operational bottlenecks that slow engineering teams down, which productivity metrics actually matter, and how engineering leaders can improve productivity with AI now part of the software delivery process.

Why developer productivity Is often Misunderstood

Many organizations still treat software engineering like a manufacturing assembly line, where more output from developers should mean more value. But Rafay Baloch, CEO and Founder of RedSecLabs, explains why it works differently in practice. 

“Lines of code or tickets closed sound like a good metric to leadership because it looks like they are getting results for their money, but it does not correlate with outcomes like a stable system, fast recovery, or the smooth, safe delivery of new features into production. Productivity is not the amount of code you write. [It’s] solving the problem you were hired to solve confidently.”

So instead of trying to maximize activity for an individual or process, engineering managers should look at the entire delivery system, focusing on: 

• Operational visibility: Learning how work flows through the SDLC, and 

• Bottlenecks and constraints: Identifying where work slows down

That’s the foundation for improving productivity and creating real value. 

Common operational bottlenecks that disrupt flow (and how to address them)

According to Atlassian's 2025 State of Developer Experience report, 63% of developers believe leadership doesn’t fully understand the barriers affecting productivity. 

Here are some of the most common bottlenecks that slow engineering teams down.

Cross-team dependencies

In practice, a feature may be technically complete yet blocked by dependencies like changes, security approvals, or platform access. “Even the simplest of tasks can get stalled if engineers have to coordinate across multiple teams just to enable a required capability,” says Clive Dsouza, Senior Software Engineer at Intuit Credit Karma.

Engineering leaders can reduce this friction by removing unnecessary approval steps. DORA’s research on platform engineering also shows that self-service capabilities and fewer manual handoffs reduce unnecessary dependencies before they become blockers, keeping the delivery flow going.

Context switching 

Delays are also often a result of context switching, when teams work on too many tasks concurrently. Baloch discusses this. 

“My main productivity bottleneck these days seems to be context switching. Developers lose focus between meetings, approvals, pings, and various communication tools (Slack, email, ticket systems), preventing them from getting anything meaningful done." 

But fewer meetings and more asynchronous communication don’t address the root cause of the problem. Leaders need to make structural changes, like consolidating work, capping how many epics engineers can work on at a time, and prioritizing tasks that align with business goals.

Unclear requirements and ownership

A 2025 systematic review of software development projects identified unclear requirements, coordination issues, and communication problems as recurring causes of project uncertainty and rework. 

Delivery often slows down when work is fed into the pipeline before the team has agreed on what needs to be built or who owns key decisions. For example, a user story may lack clear acceptance criteria, the scope may change mid-sprint, or multiple teams may assume someone else is responsible for approving a feature.

Organizations can address this problem by agreeing on ownership early, defining clear acceptance criteria, and validating requirements with stakeholders before work enters delivery. 

Downstream disorder: review, testing, and release queues

The last leg of a delivery is often the slowest. Most of the time, pull requests are waiting for review, testing environments are overloaded, and releases are waiting in the queue for manual approval. 

The Puppet State of DevOps Report shows that automation, platform capabilities, and self-service infrastructure are important for reducing delivery friction. If those capabilities aren’t in place, engineers spend more time navigating approvals and operational handoffs than delivering customer value. 

Relying on vanity metrics

When engineering leaders overemphasize activity metrics, it delays how quickly they can identify bottlenecks and make decisions. 

As James Sheridan, CEO of Sheridan Technologies, puts it: 

“I have seen engineering teams lose days or weeks because nobody had clearly defined the next decision, the test environment was unreliable, or a feature was ‘almost done’ but blocked by integration, review, or product clarification. That kind of delay does not show up if you are only looking at commits, tickets closed, or lines of code. It shows up when you look at flow.”

Which productivity metrics actually matter

Individual metrics can provide useful signals, but rarely tell the whole story in isolation. Our 4 Pillars Framework examines how work flows through the system, where constraints exist, and which improvements will have the greatest impact on delivery outcomes.

Here are the key metrics for each pillar, what they measure, and how they help improve productivity.

1. Focus

Focus measures whether engineering effort is being spent on the work with the most value. It helps leaders to identify distractions, excessive work in progress, and context switching that diminish delivery efficiency.

2. Speed

Speed measures how quickly work moves through the SDLC. 

3. Predictability

Predictability measures how consistently teams deliver against their commitments. 

4. Quality

Quality measures how teams deliver software consistently without creating unnecessary defects or technical debt. 

Explore Plandek’s full engineering metrics library to learn more about the 4 Pillars, DORA, Kanban, and other metrics. 

How to measure AI productivity 

We know that AI-assisted development can significantly accelerate code generation. But Plandek’s AI Adoption and Impact Benchmarks have demonstrated that AI adoption alone doesn’t ensure improved delivery outcomes. 

The 2025 AI Code Quality study by GitClear also found that while AI-assisted development increased code volume, code refactoring dropped from 25% to below 10%, while copy-pasted code increased from 8% to more than 12%. 

Gabriel Malinosqui, CEO of Kodus, explains the trap. 

“The old reflex with any new tooling was to measure more[...] AI made that reflex worse for a while, because people generate more code faster, and more code is not more progress.”

That’s why AI usage can’t be the only way to measure AI-assisted productivity. 

A better approach is to measure the impact of AI across the SDLC, and Plandek’s RACER framework is a useful way to assess whether AI is actually moving the needle or just inflating activity. 

Here’s what the RACER framework encourages leaders to consider.

• Rollout: Are teams actually adopting AI tools consistently, or have licenses been rolled out with no meaningful use?

• Approach: Are the tools being used for the right tasks, from coding help to autonomous agents, in line with the team’s maturity and risk profile?

• Constraints: Is AI revealing bottlenecks in code review, documentation, deployment, or governance that are now constraining overall delivery performance?

• Engineering impact: Is AI improving engineering outcomes such as speed, focus, predictability, and quality, or simply increasing code volume?

• Results: Are AI-assisted improvements translating into measurable business outcomes such as faster time to market, lower delivery costs, or improved customer value?

How Plandek supports engineering visibility and productivity measurement

Developer productivity isn’t really about how much code developers (or AI) can produce. To improve engineering performance, leaders must understand how work flows through the SDLC, remove constraints that slow delivery, and measure how outcomes align with business goals. 

Plandek brings together delivery data from across your engineering toolchain into a single Developer Productivity Insights (DPI) platform that measures the right metrics, benchmarks performance, tracks AI impact, and connects delivery data to business outcomes. This operational visibility helps engineering leaders make informed decisions about where to focus engineering effort, rather than wasting time optimizing individual developers or processes.

Contributors

• Rafay Baloch, Founder and CEO, RedSecLabs

• Clive Dsouza, Senior Software Engineer, Intuit Credit Karma

• James Sheridan, CEO, Sheridan Technologies

• Gabriel Malinosqui, CEO, Kodus