What is developer productivity?

Developer productivity (often called engineering productivity) is how well an engineering organization turns people’s time and AI tokens into outcomes that matter, and whether it can keep doing that without burning out those people. Despite its name, it predominantly belongs to teams and systems rather than individual engineers, so it shows up in how work moves from idea to production, not in how much code any one person writes.

Productivity belongs to the system, not individuals

Making one step faster means little if the work still waits everywhere else. A bug that an engineer now fixes in thirty minutes with an agent can still take the organization ten hours: reproducing it, triage, Slack threads, review, merging, and telling the customer.

Most of the time goes to the spaces between people: handoffs, review queues, waiting on decisions, and slow feedback. Teams that measure flow efficiency, the share of a task’s life when someone is actively working on it, commonly land at 15–40%. The rest is waiting.

That’s why “measure individuals harder” never works, and why AI making one engineer faster often doesn’t move the organization’s numbers much or at all.

Three questions that show whether you’re productive

Answering that takes three questions:

Are you doing the right work? Effort goes to things the business cares about instead of evaporating into keeping the lights on and surprise work. Going fast in the wrong direction just gets you to the wrong place sooner.

Is work flowing well? Things get from idea to production without getting stuck, and quality holds up along the way. This is where DORA’s delivery metrics live.

Can people keep it up? Engineers find it easy to get their job done. Burned-out engineers can post incredible numbers for exactly one quarter, and then the next thing they post is the “open to work” banner.

Build, Swarmia’s book on running software organizations, names the middle question developer productivity and treats all three as the elements of engineering effectiveness: business outcomes, developer productivity, and developer experience. There’s also a fourth thing, less a part than a test: the system keeps getting better over time. A productive organization keeps closing its own feedback loops instead of hitting a target once.

What developer productivity isn’t

Developer productivity isn’t lines of code, pull requests per engineer, commits, story points, utilization, or AI adoption percentage. AI has made code cheap to produce, so counting it tells you less than ever. Utilization backfires on its own terms: as it nears 100%, cycle times climb and teams slow down.

AI adoption is worth tracking as an input. In Swarmia’s Q2 2026 benchmark (n=352) in the Build framework, the top quarter of organizations already had AI assisting 82% or more of merged pull requests, so adoption alone says little about who’s shipping more value. To see what to track alongside it, read which software development KPIs to track.

Measure what matters in an agentic organization

Swarmia’s Build framework lays out the metrics, benchmarks, and practices for getting real returns from AI across the whole software organization.

Read the Build framework