Developer productivity: why your engineering team is slow
When developer productivity drops, the cause is rarely the developers. In a slow team, capable engineers usually spend their days waiting: on decisions, on reviews, on a deploy pipeline nobody trusts, or on another part of the codebase they can’t change without breaking something.
This is a diagnostic for founders and engineering leaders who can feel that delivery has slowed but can’t say why. Work through the causes in order. They’re ordered by where I’d look first, not by how interesting they are.
First, check that it’s actually slow
“Slow” often means “slower than I expected”, and expectations are frequently the problem. Before diagnosing the team, collect three facts for the last two months:
- What shipped, week by week, in plain language. Not story points.
- How long a typical change takes from first commit to production. This is the lead time from DORA metrics, and you can get it from Git and your deploy log.
- How much time went to unplanned work: incidents, urgent customer requests, sales-driven one-offs.
If shipped work is steady but unplanned work is eating half the week, you don’t have a velocity problem. You have a priority or quality problem, covered below.
Cause 1: unclear or shifting priorities
This is one of the most common causes of slow software delivery, and the one engineering teams can’t fix themselves. Symptoms: lots of work started, little finished; engineers asking “which one first?”; priorities that change in the Monday meeting and again on Thursday.
Every context switch throws away the half-built mental model of the last task. A team with five things in flight per person will feel busy and ship little.
- Fix: one ranked list, owned by one person, changed at most once a sprint except for genuine emergencies.
- Fix: limit work in progress. A simple rule like “no more than one in-progress ticket per engineer” surfaces the blockage fast.
- Fix: write down what “done” means for each piece of work before it starts. Vague scope is how a two-day task becomes two weeks.
Cause 2: the review queue
If your engineers finish code on Tuesday and it merges on Friday, review is your bottleneck. It’s invisible to anyone not looking at pull request timestamps, and it’s usually the single biggest drag on engineering velocity in teams of five to fifteen.
It gets worse in a predictable way: PRs wait, so people batch more into each one, so they take longer to review, so they wait longer.
- Measure time to first review. Most Git hosts expose it through their API. If the median is over a working day, start here.
- Keep PRs small. A few hundred changed lines is reviewable in one sitting; two thousand is not.
- Make reviewing a first-class job. Review before starting new work. A daily review slot or a rotating reviewer works better than goodwill.
- Stop requiring two approvals by default unless the change touches money, auth or data deletion.
Cause 3: deploys nobody trusts
A flaky test suite, a manual release checklist or a deploy that sometimes takes the site down produces the same behavior: teams deploy less often, batch changes, and each deploy becomes riskier. Fear compounds.
Signs: releases happen on a fixed day, someone has to “babysit” the deploy, CI gets rerun until it goes green, and nobody deploys on Fridays.
- Quarantine flaky tests immediately and fix or delete them within a week. A suite people rerun is a suite people ignore.
- Get CI under ten minutes for the common path. Parallelize, cache dependencies, move slow end-to-end tests to a separate stage.
- Make rollback one command and practice it. Write migrations so the previous release still runs against the new schema.
- Deploy on every merge to main. Small deploys are boring deploys.
This is often the quickest win available. If you want hands-on help, it’s the core of my DevOps consulting work.
Cause 4: coupling in the codebase
When every feature touches the same five files, engineers step on each other, merge conflicts multiply, and a change in billing breaks the onboarding flow. The team slows down not from lack of effort but because the code makes every change expensive.
You’ll hear it as “we can’t touch that”, “only one person knows how that works” and estimates that are always padded for unknown side effects.
- Find the hotspots. Files that change most often and break most often are where coupling hurts. Your Git log will tell you which they are.
- Draw module boundaries inside the monolith before reaching for microservices. A modular monolith gets most of the benefit without the operational cost.
- Pay down debt in the path of work. Refactor the area you’re about to change, as part of that change. See how to reduce technical debt for a fuller approach.
Cause 5: missing decisions and missing seniority
Some teams have plenty of capable engineers and nobody with the authority or experience to make architecture calls. Questions sit in Slack threads for days. Two engineers build the same thing two ways. Big decisions get made by default.
This is common after a founding CTO steps back, or in teams that grew from three to twelve without anyone moving into a lead role. Hiring more engineers won’t help; it adds more people waiting on the same missing decisions.
The fix is a person whose job includes deciding, reviewing and unblocking. That can be an internal promotion, a hire, or a temporary embedded engineering lead who does the job while growing the person who will own it.
What usually doesn’t help
- Adding headcount. New engineers need onboarding, reviews and decisions, which are the very things in short supply.
- A new project-management tool. If priorities are unclear in Jira they’ll be unclear in Linear.
- Story-point targets. Teams hit them by inflating estimates. See software estimation for what to use instead.
- A rewrite. Rarely the answer to slowness; the same team, process and priorities will produce the same result. Read rewrite vs refactor before you commit to one.
A one-week diagnostic you can run yourself
- Pull median PR time-to-first-review and time-to-merge for the last 60 days.
- Pull deploy frequency and the number of rollbacks or hotfixes in the same period.
- Ask each engineer privately: “What slowed you down most last week?” Write the answers down verbatim.
- List everything currently in progress. Count items per engineer.
- Pick the single biggest cause and fix only that for a month. Then measure again.
Questions
How do you measure developer productivity?
Measure the system, not individuals. Lead time from commit to production, deployment frequency, change failure rate and time to first review tell you where work waits. Pair them with a simple weekly list of what shipped. Avoid lines of code, commit counts and story points as productivity measures.
Why is my engineering team slow even though they work hard?
Usually because work waits between steps: for priorities to settle, for code review, for a deploy slot, or for a senior person to make a decision. Hard work doesn’t move a queue. Find where tickets sit idle and fix that step first.
Will hiring more developers increase engineering velocity?
Not if the bottleneck is review, decisions or deploys. New hires add load to exactly those steps during onboarding. Fix the constraint first; then extra engineers turn into extra output instead of a longer queue.
How long does it take to fix slow software delivery?
Process fixes such as review rotations and work-in-progress limits can show results within weeks. Pipeline fixes like faster CI and reliable rollbacks often take a month or two. Untangling a tightly coupled codebase is a longer project measured in quarters, done alongside feature work.
Can feel the slowdown but can’t name it?
I’ll join your team for a two-week sprint, find where work is waiting, and ship the first fix alongside your engineers. If it doesn’t help, we stop.
GMT+2 · Full EU overlap · US East mornings