Why Your Team Is Shipping Slower Than Before (and How to Find the Real Cause)

If your team is shipping slower than before, the cause is rarely effort. It is usually a change in how work flows through the pipeline, how risky each change has become, or how the people doing the work are feeling. Pushing harder on a team in that state tends to make the underlying problem worse.

Each of those causes leaves a different trace in your data, and each calls for a different fix. Below, you will see how to confirm the slowdown is real, what typically causes it in startup engineering teams, and how to work out which cause applies to you before you act.

Confirm the Slowdown Is Real Before You Fix Anything

Start by deciding what "shipping" means for your team. Deploys, merged pull requests, and completed issues each measure something different. Deploys reflect what reaches customers, merged PRs reflect code integration, and completed issues reflect planning discipline as much as output. Choosing one by feel is how teams end up solving a problem they do not have.

Once you have a primary metric, compare like for like. A trailing window of six to eight weeks against the prior period of the same length smooths out the noise of any single sprint. Then adjust for the things that distort the comparison:

• Holidays and time off: a window that includes a company break will look slow regardless of how the team is doing.
• Release cycles: a big launch can pull work forward and leave the following weeks quiet.
• Team size: if headcount changed, look at output per engineer as well as in total, and remember new hires take months to reach full speed.
• Incident and support load: unplanned work consumes capacity without showing up as planned throughput.

Counts alone can also mislead. Suppose ticket throughput fell from 40 per month to 28, but deployments held steady. That pattern can mean the team moved from small fixes to a few large, hard projects, such as a billing migration or a new permissions model. Fewer tickets closed, but more meaningful change delivered. Check the size and type of work alongside the count before drawing conclusions.

It is also worth separating throughput (how much work completes in a period) from lead time (how long a single change takes from request to production). A team can hold throughput steady while lead time stretches, and that is often the first sign something in the flow has changed. If, after all of this, the slowdown still shows up across more than one metric and more than one window, it is real and worth diagnosing.

Growth Overhead: Why Adding People and Code Slows Delivery

Many startup slowdowns are the price of growth, not a sign anything broke. In 1975, Fred Brooks argued in The Mythical Man-Month that adding people to a software project does not add output proportionally, and the idea became known as Brooks's Law. The reasoning is simple: every new person adds communication paths, and each path has a cost.

In practice that cost appears in several places at once:

• More reviewers and approvers, so each PR waits on more calendars.
• More handoffs between design, backend, frontend, and QA, each a place for work to sit idle.
• More meetings to keep everyone aligned.
• Onboarding, which pulls your most experienced engineers away from feature work to answer questions and review unfamiliar code.

The codebase grows alongside the team. A larger system means engineers touch unfamiliar areas more often, switch context more frequently, and cause wider side effects when they get something wrong. The blast radius of a single change increases, which makes people more careful, and careful takes longer.

The typical startup curve

Many founders recall the early days, with three to five engineers, as the fastest the company ever moved. Everyone knew the whole system, decisions happened in a hallway conversation, and nobody waited for permission. As the team passes the point where everyone knows everything, that shared context disappears and has to be replaced with documentation, ownership boundaries, and process.

The mistake is comparing today's velocity to that earlier period and concluding the team got worse. The team got bigger and the system got more complex, and the work now includes coordination that used to be free. The useful question is whether the overhead is proportionate or whether it has grown faster than the team. Unclear ownership, a single overloaded reviewer, or an architecture that forces every feature to touch the same module are signs it has.

Stalled Work and Hidden Bottlenecks in the Pipeline

Cycle time, the elapsed time from starting work to delivering it, is a single number that hides several stages: coding, waiting for review, review itself, merge, and deploy. When it grows, the instinct is to assume engineers are coding more slowly. More often the longest stage is idle time, especially a PR sitting untouched in the review queue.

The DORA research program (Google Cloud's DevOps Research and Assessment) gives useful shared definitions here. Lead time for changes measures how long it takes a committed change to reach production, and deployment frequency measures how often you release. Both are worth tracking over time, and you should check the most recent DORA report before comparing your numbers to any published benchmark, since the thresholds and framing have been updated across editions.

Signs of stalled work

• PRs open for days with no comments or commits.
• Issues marked in progress with no linked branch, commit, or PR activity.
• Work that is repeatedly reopened, reassigned, or bounced back from review.
• Several initiatives each "almost done" and none finished.

Two causes sit behind most of these. The first is unclear ownership: when nobody is clearly responsible for reviewing a change or unblocking a ticket, it waits for someone to notice. The second is too much work in progress. Each engineer juggling four items spends effort switching between them, and every item takes longer to finish. Limiting work in progress feels counterintuitive, because it looks like doing less, yet finishing fewer things in parallel usually raises the rate at which things actually get done.

A quick test is to list everything currently in progress and compare it with the number of engineers. If the ratio is well above one item per person, or if the oldest items are weeks old, the bottleneck is likely flow and not skill or effort. Fixes tend to be modest: review-time expectations, a rotating reviewer, a rule that finishing beats starting, and a weekly look at the oldest open work.

Technical Debt and Change Pressure: When Each Release Gets Riskier

Technical debt rarely announces itself. It shows up as code churn, meaning code that is rewritten or deleted shortly after it was written, as repeated edits to the same handful of files, and as a growing share of hotfixes following merges. When the same modules attract change after change, they are usually fragile, tightly coupled, or poorly understood.

Change pressure is a related idea: how much change is concentrated in a short period, such as merge volume piling up before a release. The more changes land at once, the harder it is to know which one caused a problem, and the higher the deployment risk. Teams that feel this respond by adding checks, slowing merges, or batching releases more carefully.

That response is often rational. A team that slows down because the last three releases broke production is protecting customers and its own sanity. Treating that caution as a performance failure and demanding speed tends to produce more incidents, which produce more caution, and the cycle repeats.

Deliberate caution versus drag

The distinction matters because the remedies differ:

• Slowing because releases keep breaking: look at test coverage, release size, rollback ability, and the files with the highest churn. The fix is investment in stability, such as smaller releases, better tests, and paying down debt in the hot spots.
• Slowing because of queues and process: look at review wait times, approval requirements, and handoffs. The fix is removing waiting, not adding safeguards.

Telling them apart comes down to evidence. Rising hotfix counts, reverts, and incident follow-ups point toward debt and risk. Long idle gaps with few defects point toward process. Many teams have both, and the data helps you decide which to address first.

The Human Factor: Morale, Momentum, and Burnout

Output often lags behind morale. By the time delivery numbers drop, the people doing the work may have been struggling for weeks. Some signals appear in everyday engineering activity: fewer comments on code reviews, shorter or emptier PR descriptions, more commits late at night or on weekends, and thinner participation in discussions and planning.

Momentum is worth watching as a direction, not a snapshot. A team completing 30 items this week tells you little. A team that completed 40, then 35, then 30 over several weeks is decelerating, and that trend is more informative than any single figure. The reverse is also true: a low week after a big release may simply be recovery.

What to check in one-on-ones

Activity data can tell you where to ask, but the explanations come from conversation. Common causes worth raising:

• Unclear priorities: engineers who are unsure what matters most spread themselves thin or wait for direction.
• Reorgs and changing ownership: they reset context and create uncertainty about who decides what.
• Constant interruptions: support requests, urgent asks, and meetings fragment focus time.
• Pressure after a missed deadline: teams often respond to criticism by becoming more defensive, more cautious, and less willing to take on ambitious work.

A caution applies here. Engineering activity data is a prompt for questions, not a basis for judging individuals. Ranking engineers by commit counts or flagging someone for working late turns a diagnostic tool into surveillance, and it will teach people to game the numbers or stop trusting you. Look at team-level patterns, and use individual observations only to start a supportive conversation. If you do see signs of strain, the right first move is usually to ask what is getting in the way, then remove it.

A Practical Way to Diagnose Your Own Slowdown

You can work through this in a few steps, and none of them require new tooling to begin:

1. Pick one throughput metric and compare the last six to eight weeks to the previous period, adjusting for holidays, releases, and team size.
2. Break cycle time into stages. Measure time to first review, time in review, time to merge, and time to deploy. Find the stage that grew.
3. Check change pressure and churn. Look at merge volume before releases, repeated edits to the same files, and the number of hotfixes or reverts.
4. Talk to the team about what you found. Present the data as a question, not a verdict.

Then match symptom to likely cause. Long review waits and old open PRs point to process and ownership. Rising hotfixes, reverts, and concentrated churn point to technical debt. Quiet reviews, declining participation, and a downward momentum trend point to morale. Most teams find one dominant cause and one or two contributing ones, which is useful, because it tells you what to fix first.

Doing this by hand across Linear and GitHub takes time most engineering leads do not have. Progress is an AI-native engineering intelligence platform that, as of 2026, ingests data from tools like Linear and GitHub and surfaces stalled work, deployment risk based on merge volume and churn, team momentum, and morale signals. Instead of building the analysis yourself, you can ask in plain language what changed over the last month and get an answer grounded in real activity. It is a way to shorten the step from noticing a slowdown to knowing where to look, and it still depends on you having the conversation with your team.

Treat the Slowdown as a Symptom, Then Measure One Stage This Week

A slowdown has several possible causes: growth overhead, stalled flow, accumulated debt, or a team running low on energy. Each looks like the others from the outside, which is why pushing for speed so often misfires. What separates them is evidence, and you can start collecting it right away.

This week, choose one stage of your pipeline, such as the time from PR opened to first review, and measure it against the previous two months. Then sit down with the team and ask what the number looks like from their side. That single, specific conversation will tell you more than another round of pressure ever could, and it gives you something concrete to bring to founders or investors who want an explanation.

Learn more about our services