The real reason your team’s velocity isn’t improving

Estimated reading time: 7 minutes

Too much focus on the speed of output can have significant consequences on your velocity.

The speed at which teams can turn ideas into usable features is an integral aspect of every engineering organization. But optimizing for speed can be a red herring – when teams lack alignment, apply different code standards, or are spread too thin across feature work, speed alone is not going to fix deeper issues. Producing an effective team that ships high-quality software can only be achieved when a team is functioning at high velocity and is aligned, working consistently and deliberately towards a shared set of agreed-upon outcomes.

Velocity killers are all too common in engineering orgs, so how can you implement the right metrics and avoid traps effectively? Here are the three primary aspects that act as velocity killers and how to move beyond them.  

1. Overcommitment

We’ve all been in a situation, either as an individual contributor, team lead, or manager, where you’re keen to impress and make an impact on your company and the product you build. Every engineering team I’ve ever worked on has been inundated with requests for new features or bug fixes, as well as having to juggle their own internal roadmap. 

You will always have more work than you can ever do. A team that is spread too thin or is constantly weighed down by the requests of other teams can never truly invest in what they are building. 

Having too much “work in progress” is a symptom of a lack of focus; everything is rushed or completed to a lower standard of quality. In the short term, this can feel like velocity, but you’ve now created two problems for your team in the future:

1. Every time you say yes to another request, it’s harder to say no in the future to that team. You’re trying to do someone a favour, but you’ve actually only set a precedent that will create more requests in the future, distracting you from your truly important work.
2. You might have shipped the work in the short term, but the lack of focus and quality will undoubtedly mean revisiting it to fix bugs and problems that arise later.

As a leader, you have to say no to protect your team. If you are in a position where you determine a team’s roadmap and workload, you have to be ruthless. Ruthlessly prioritize work that is important for your roadmap and guard it. 

If unexpected high-priority work comes in, something else must be removed. Recently, my team was asked to take on a multi-month project at short notice due to a shift in team structure. We were able to do this, but only after explicitly outlining other prioritized work and deciding which would be dropped to make room. We let go of work that still mattered, but not to the level of the new project. It was a tough call, but a necessary one. 

Let your team focus on a few highly important tasks and do them well. 

2. Process paralysis

Processes are an important aspect of a successful roll-out: from ideation, to design, to implementation, and then launch, each stage plays a part in a smooth project flow. For instance, if there have been significant code changes, time will have to be allocated to perform code reviews punctually. A significant feature launch may also require additional accessibility and UX validation or attention from security teams. 

These review steps can be necessary, but processes only grow over time – they never shrink.  I’ve seen teams spend one week building a feature and four weeks getting required sign-off from across the business before it could go live. Not only is this a large time cost, but it also kills an engineer’s momentum, eating into morale boosts that are gained from completing features. If you take that buzz and gate it behind endless bureaucracy and sign-off, you’ll be killing your team’s enthusiasm, and everything will move slower.

As a leader, you are well-positioned to suggest reductions in process based on your team’s feedback. Schedule regular points in time to review your processes and consider their utility; can you reduce the number of steps? Or, can you provide your team with room to make judgment calls? Perhaps features that are less impactful or technically complex can go through a lighter review process, or even be reviewed post-launch. It’s much nicer to step back and trust your team to make the right decision. Introduce a new process only when a problem could have been avoided by having it.

3. The overhead of context switching

Context switching can silently have a huge impact on your team’s velocity. This can present itself in different ways:

1. Each engineer on the team can be spread so thin that they are constantly jumping between work or revisiting old work that has bugs.
2. An engineer can have a small number of projects, but if each one is in a completely different area of the codebase, they are constantly getting up to speed. In this case, you can consider reallocating work to allow each engineer to stay within one focus area for a period of time. This means when they move from feature to feature, they don’t spend time ramping up.
3. If an engineer is spending too much of their time in meetings, they never have long enough to become fully immersed in their work. We all know that two thirty-minute chunks spliced between meetings are much less valuable than an uninterrupted hour. 
4. Finally, be sure to watch out for those urgent requests. These can pull people out of their context very suddenly. In my experience, urgent work is rarely urgent. Maintain a high bar for what is “urgent.” Work that is important but not urgent can be prioritized through the usual process.

There are three techniques that can be very impactful for reducing context switching across a team:

1. Clump meetings together. On my team, we assign Tuesday afternoons as our meeting time. Any team meeting goes in this slot, and we also try to group smaller meetings, or 1:1s, into this too. This gives people larger chunks of time to get their heads down.
2. Group related projects in planning. Try to keep the same engineers assigned to related features so they can move between them and apply the relevant context. You have to apply some caution here – over time, you don’t want to silo your engineers, and you want to ensure knowledge is spread across the team. Reserve this approach for short to medium periods of time. 
3. Have a clear prioritization process. Make sure other teams understand how to propose work that needs doing. Ensure your team doesn’t get constant pings on chat from people trying to sneak work in. Define a process and stick to it, and ask people to come to you with requests or questions. Shield your team from interruptions whenever possible.

Measuring velocity

Another challenge of engineering velocity is that it’s incredibly hard to measure. Trying to find any numerical value is nearly impossible. There are some common metrics that engineering orgs like to lean on, but each has its problems:

• Using “story points” – This relies on your estimates being accurate, which they inevitably won’t be, at least not consistently enough to track over time.
• Using “lines of code” or “pull requests” – This assumes each change is even, which it isn’t. It devalues large, complex changes and values frequent, smaller ones. The number of changes typically bears little relation to complexity or the amount of work shipped.
• Metrics should be resilient to outside factors – A useful metric should still make sense even when plans change, like a teammate being on holiday for a month, or an urgent task coming in at the last minute that disrupts the usual planning structure. 

Instead, it’s best to focus on trends over time and ask your team members directly for feedback. Consider asking them:

• Do they feel happy with their momentum and work being shipped?
• Do they regularly complete their planned work?
• Are we confident overall with the accuracy of estimates?
• How much work does an engineer have assigned at any given time? Is this an acceptably low number?

Velocity is a combination of some metrics, such as the amount of work in progress, or how many features were shipped in a given period, but needs to be combined with sentiment from the team – how do they feel? Generally, if a team is happy and feels productive, more work will be done to a higher quality. Everything else is secondary to that.

October 15 & 16, 2025

Agendas for New York events are live! 🙌

See who’s speaking

Velocity is a sustainable pace

True engineering velocity isn’t about sprinting as quickly as possible to ship as many changes as possible. It’s about finding the balance where you ship an acceptable amount of features in a sustainable manner, ensuring the team feels productive and positive about their workload. 

If you can take a step back and help your team plan effectively, say no to incoming requests unless truly urgent, and be ruthless at ensuring all processes are worth the overhead, you’ll be well on your way to an effective engineering process and team.