Devint

Performance evaluation

Is your tech team delivering late? 6 common causes

Eduardo Missaka
CEO and Founder of Devint
Published · Updated · 9 min read
In this article

When the date promised to the market slips, the question that reaches the business side is almost always the same: what happened? Late software delivery rarely has a single cause. This article covers six common causes of a tech team delivering late, described from what business leaders can see from the outside, along with questions that help you talk to the CTO without turning it into blame.

In short

  • Delays rarely come from a single cause, or from a lack of effort: they usually result from scope, dependencies, review, rework, capacity, and hiring acting together.
  • Each cause leaves a visible symptom for the business, such as a date that changes at the last minute or a delivery that stays “almost done” for weeks.
  • The six causes covered here are scope that changes midway, dependencies between squads, a code review bottleneck, rework and technical debt, poorly sized capacity, and hiring that does not turn into delivery.
  • For each cause there is a question the business side can bring to the CTO to understand the problem without blaming or monitoring anyone.
  • Software delivery predictability depends on spotting these signals, such as development bottlenecks and team capacity limits, before the crisis meeting, not after it.

Why the tech team delivers late and nobody can explain it

The launch of a product or a system update was scheduled for the end of the quarter. Sales had already told customers, marketing had already scheduled the campaign, and suddenly the tech team asks for more time. At the next meeting, the reason comes in technical terms and the conversation ends without a clear answer to the question that matters to the business: what changed, and when will it be ready?

Anyone who works in product and business knows this scene. It tends to be read as a lack of commitment or competence from the team, and it is almost never that. More often, the delay is the end of a chain of small blockages that stayed invisible to people outside the day-to-day of engineering.

The six causes below are described from the point of view of someone who does not read code. For each one, you will find what the business sees (the symptom), what usually lies behind it (the real cause), and a question to bring to the CTO.

Cause 1: scope changes along the way

What the business sees: the date is agreed, the team starts and, a few weeks later, the delivery has “grown”. Adjustments requested by customers, a new requirement from another area, or a detail nobody had foreseen come in.

What usually lies behind it: the estimate was based on a scope that was not yet closed. Each change looks small when it is requested, but it requires reopening decisions already made, redoing parts already built, and reassessing what depends on them. The original deadline stays on the calendar even after the work has changed size.

Question to bring to the CTO: what has entered the scope since the date was agreed, and was the date renegotiated along with each addition?

Cause 2: dependencies between squads create queues nobody controls

What the business sees: a feature that seemed simple does not close because “a piece from the other team is missing”. Each squad says its part is almost ready, but the whole does not arrive.

What usually lies behind it: when a piece of work only finishes after passing through more than one squad, it starts to wait in a queue between one stage and the next. Work that is started and not finished piles up, and interruptions to unblock one part pull focus away from the others. It is worth remembering that the total time of a delivery (lead time) grows with the number of items in progress at the same time, and that long stoppages affect the cycle deadline.

Question to bring to the CTO: which important deliveries depend on more than one squad, and who is tracking what each one is waiting on from the other?

Cause 3: a code review bottleneck leaves work stuck

What the business sees: the delivery has been “ready” for days, but it does not go live. The team says only the review is missing.

What usually lies behind it: before entering the product, code written by one person must be reviewed by another, in a review request called a pull request. When these requests pile up, work already done sits idle, loses context, and tends to cause conflicts with whatever changed in the meantime. According to Software.com, slow review is a bottleneck that is easy to overlook, and high-performing teams usually review a pull request less than a day after it is opened.

Question to bring to the CTO: how long, on average, does finished work from a dev wait to be reviewed? Is that time being monitored?

Cause 4: rework and technical debt consume the next cycle’s capacity

What the business sees: a delivery that had already been called done comes back with problems, and the team says it needs to “fix the foundation” before moving on with what was promised.

What usually lies behind it: part of the work that went into the product in a hurry has to be corrected or reorganized later. This cost, called technical debt, does not appear in any delivery plan, but it comes out of the same team capacity. The more time spent fixing what was already delivered, the less is left for what is still to be built.

Question to bring to the CTO: what share of the team’s time is going to fixing or adjusting what has already been delivered, instead of building what is in the plan?

Cause 5: team capacity estimated above what exists

What the business sees: the quarterly plan looked reasonable on paper, but the team consistently delivers less than agreed, cycle after cycle.

What usually lies behind it: the plan assumes the whole team is dedicated to delivery, while reality includes vacations, production support, meetings, maintenance, and interruptions. InfoQ Brasil (in Portuguese) points to the lack of tracking of actual work against estimates as a cause of delay, which prevents the team from calibrating future estimates.

Question to bring to the CTO: in recent cycles, how much was planned and how much was delivered, and what share of capacity is really available for the business’s priorities?

Cause 6: hiring more people does not raise delivery proportionally

What the business sees: the team grew, the investment went up, and the date keeps slipping, sometimes even more than before.

What usually lies behind it: newcomers need time to become productive and take time from existing team members to be trained. In addition, the bigger the group, the more communication is needed to keep everyone aligned. This effect is known as Brooks’s law, formulated by Fred Brooks in 1975 in the book The Mythical Man-Month: adding people to a software project that is already late tends to make it later. Brooks himself described it as an outrageous oversimplification, but one that captures the general rule.

Question to bring to the CTO: are the latest hires already delivering at the expected pace, and what has changed in the team’s capacity since they arrived?

What the six causes have in common

In all of them, the problem starts weeks before the date slips: a review queue that grows, a dependency that was never agreed, a capacity that was never measured against the plan. The business only finds out when the effect reaches the calendar, which is why the question “what happened?” always comes late.

Software delivery predictability, therefore, does not depend on pressuring the team for shorter deadlines. It depends on giving business leadership a regular reading, in terms of delivery, capacity, and return, that shows where the flow is getting stuck while there is still time to act.

How Devint helps you see these signals before the delay

Devint gives business leadership a reading of delivery pace and team capacity at each biweekly close, useful for identifying software development bottlenecks and comparable from one cycle to the next. It points to where it is worth investigating without exposing individuals and without replacing the conversation with the CTO. See how Devint makes delivery predictability visible to your leadership.

Frequently asked questions

Why does the tech team deliver late even when everyone works hard?

Because effort and delivery are different things. A team can be busy all the time and still deliver little if work waits in a review queue, depends on another squad, goes back for fixes, or changes scope. Delay tends to be born in those gaps, where nobody is working on the item, and not in the speed of the people writing code.

How can you tell whether a software delivery deadline is realistic?

Compare what was planned with what was delivered in recent cycles, instead of looking only at the plan for the next one. If the team usually delivers less than it commits to, the new date repeats the mistake. It is also worth asking what depends on other squads and how much work is stuck waiting for review.

Does hiring more developers fix late deliveries?

Not always, and on a project that is already late it can make things worse. Newcomers need time to become productive, take time from the existing team, and increase the communication required. Before hiring, find out whether the limit is a lack of people or a bottleneck in the flow, such as review and dependencies.

How can you improve software delivery predictability without turning it into surveillance?

By measuring the work, not the people. Questions about review queues, dependencies, rework, and available capacity show where the flow gets stuck without requiring real-time tracking of anyone. The number serves to open the conversation with the CTO about where to investigate, not to decide promotions or dismissals.

How do you measure software delivery predictability?

Start by comparing, cycle by cycle, what was planned with what was delivered. Add the lead time (the time between starting and finishing a delivery), the time work waits for review, and the share of capacity spent on rework. The goal is not a single number, but a regular reading that shows the trend.

Sources

See the DevScore applied to your team.

Book a demo