Why is my dev team so slow?

The question arrives in my inbox in roughly the same words every time. "My dev team is so slow. I do not understand why." The founder usually follows it with a list of things they have already tried. A new tool. A new standup format. Two more engineers. None of it moved the needle.

The reason none of it worked is that slow is a symptom, and they were treating it as the disease.

I have spent 22 years inside and alongside engineering teams. When a founder tells me the team is slow, I ask them to describe what slow looks like in practice. The answer tells me most of what I need to know.

What founders usually mean by slow

"Slow" hides at least four different complaints, and they point in different directions.

Nothing ships. Work starts, work is discussed, work is in progress, and the release date keeps moving. This is usually a flow problem. Work is entering the team faster than it leaves.

Small things take forever. A copy change or a one-field form takes two weeks. This is the clearest signal of a structural problem, because the work itself is trivial. Whatever is slow is the path the work travels, not the work.

Estimates are always wrong. The team commits to a date and misses it, then commits to another and misses that. When the miss is consistent and the explanation changes every time, the team has lost the ability to see its own work clearly. I wrote about what that looks like in signs your startup needs a tech mentor.

They seem busy but I cannot see output. Standups happen, tickets move, engineers look occupied. Output does not appear. Usually this means work is being done on the wrong things, or the same thing is being done twice by people who did not know the other was doing it.

Write down which of these you are actually experiencing. If it is more than one, note which one came first. That is often the root.

The four places slowness actually comes from

Almost every slow team I have looked at was slow for one of these four reasons, or a combination. The order matters, because founders tend to jump to the first one and it is usually the least likely.

The people

Sometimes a team is slow because an individual cannot do the work at the level the seat requires. It happens. It is also the explanation founders reach for first and the one that is true least often, because a struggling individual slows their own work, not the whole team's.

Signs it is people: one area of the product is consistently late while others are fine. Reviews from one person take days while others take hours. The same engineer is the one every delayed ticket is waiting on, and it is not because they own too much.

If you cannot tell whether someone is performing at the level their role requires, that is a visibility problem rather than a performance problem. I cover how to close that gap in how to evaluate your engineering team as a non-technical founder.

The roles

This is the cause I find most often and the one that is hardest to see from outside. The team has titles. It does not have ownership.

Signs it is roles: ask three engineers who owns a specific part of the product and get three answers, or three shrugs. A tech lead who is still writing most of the code and has no time to unblock anyone. Two people who both think the other one is handling deployments. A senior who is doing junior work because nobody redefined the seat when the team grew.

Work slows down at the edges of undefined roles, because every handoff becomes a negotiation.

The process

Early teams usually have too much process or too little, and both look the same from a founder's chair.

Too much: ceremonies carried over from someone's previous employer, an approval chain for every change, planning that takes a day out of every fortnight. The team spends its time reporting on work rather than doing it.

Too little: no branch protection, no automated tests, no code review, so every release is a manual event that someone dreads. Work ships and then comes straight back as bugs.

Signs it is process: engineers can tell you what they are building but cannot tell you when it will reach users, because that depends on a queue they do not control. Or releases are rare, large and frightening.

How work reaches the team

The cause founders almost never consider is themselves.

Work that arrives as a one-line request with no definition of done gets estimated as a guess, built as a guess, and reworked when the guess was wrong. Priorities that change weekly mean nothing gets finished before the next thing starts. A founder who drops directly into an engineer's messages with "quick question, can you just" is a hidden source of context switching that never shows up in any tool.

Signs it is intake: the team's most common status is "waiting for clarification". Work that was started is abandoned when priorities move. Engineers can describe what they are doing but not why it is the priority this week.

What to look at first

Do not start by interviewing the team about why they are slow. You will get four different theories and none of them will be the system.

Start by tracing work. Pick five recent pieces of work, ideally a mix of large and small, and follow each one backwards from the moment it reached users to the moment someone first asked for it. Write down every place it sat waiting and what it was waiting on. A clarification. A review. A test environment. A decision from you.

Then look at the list. The waiting will cluster somewhere. That cluster is your bottleneck. It is almost never where the team assumed, and it is usually not in the writing of the code.

Two numbers from your existing ticket tool will confirm it. Cycle time, the elapsed time from starting a piece of work to it reaching production. And how much work is in progress at once. If in-progress work is high and cycle time is long, the team is starting far more than it finishes, and adding more people will make that worse.

I go into the metrics that actually tell the truth, and the fixes for each cause, in how to improve engineering team performance. This piece is the diagnosis. That one is the treatment.

What not to do

Do not hire more developers yet. Every engineer you add to a team with unclear ownership is another person who has to ask who owns what. Fred Brooks wrote this down in 1975 and it is still true: adding people to a late project makes it later, because the coordination cost grows faster than the output. Hire when you can name the specific gap the hire fills.

Do not change the tool. Moving from one ticket tracker to another moves the same broken flow into a different interface. If the team is slow in Jira it will be slow in Linear.

Do not add a ceremony. A new meeting to discuss why things are slow is another thing that is not shipping.

Do not announce a velocity target. Velocity is easy to inflate and tells you nothing about whether users got anything. Measure cycle time and finished work instead.

Do not ask the team to work harder. If the system is the problem, harder means the same broken flow at higher cost, and you will lose your best people first.

Slow is a diagnosis you can make

A slow team is a team where work is waiting somewhere, and the waiting has a cause. Trace five pieces of work and you will usually find it inside a week. If what you find is roles or process, the fix is a redesign, and I have written up how I approach that. If what you find is unclear, that is what a diagnosis from outside is for.