Beyond Speed: The missing component in most velocity debates

Speed Is Only Half the Equation

If you are an engineering leader, chances are you have been asked to discuss your team’s velocity many times over and chances are when you get this question your mind goes into computing how to get out of this conversation as quickly as possible :).

I get it, I’ve been there. Over the many debates about velocity something hit me, most of these conversations are around speed. Get the team to ship faster, do more, why does it take so long to ship code. These are all valid and important issues to dig into and help your team with. But if you really want to improve your team’s velocity, speed alone doesn’t get you better results. Speed will get you more output but when it comes to delivering results for the business, you need to compliment speed with 🥁🥁DIRECTION.

So what is the definition of velocity?

It’s important to make sure that there is alignment and understanding that velocity is speed AND direction. This AND part is really important because going fast in the wrong direction will not get you where you need to go as a team or a business.

When you are navigating to a location, you care first about reaching your destination. Sure you want to look for the shortest or fastest route but if going fast doesn’t get you where you need to go, I would imagine you wouldn’t just take that fast route to nowhere.

It’s about the destination

Once you agree on the definition, come back to the velocity conversation and dive in to help debug what is going on with the way your team is working. Have no fear, this is a really great conversation to have and your time will be well spent to understand whether your team is blocked by issues on the execution side or running fast but in a completely different direction.

Speed

If you identify that your team is struggling to ship, your issues are likely on the execution side. Spend time identifying what impediments are getting in their way. Most teams are working really hard. From my experience, this notion that developers are lazy is rarely the case. What I see more often is that the team is working hard but to get that small change out, they are battling with flaky tests, suboptimal pipelines, poorly defined iterations of work, over-engineered solution, and so on. I have also seen it where the way the work is assigned leads to inefficiencies (too much context switching, lack of documentation, lack of clarity on deliverable, lack of focus, etc). All this friction gets in their way to deliver value and you need to help the team debug and put together a plan to address these issues. If the issues are vast, consider putting together an Engineering ‘roadmap’ with the team and help them execute on a plan to address these issues, iteratively. Worth noting, there are times when you need to make drastic changes. Your team will need your support to make these hard decisions.

Direction

This is where I don’t see a lot of conversations happening. If the team is able to ship and deliver quality code to production, then your issues around velocity are coming from lack of perceived value from the work the team is doing. It is an issue with direction. Debugging direction issues is fun (but much harder I will tell you). This is more about how well your team is doing Product. Are they an Empowered product team or a Feature team? I like how this post positions the issue and offers notes to get you on the path to be an empowered team.

Here’s a snippet

Rather than providing the product team with a roadmap of features and projects to build, the product team is instead given a set of problems to solve and desired outcomes to achieve.

This means coming up with a solution that is valuable – the customer will buy or choose to use; usable – the user will be able to figure out how to use; feasible – our engineers know how to solve with the time, skills and technology on the team; and viable – the solution will work for our business in terms of constraints in marketing, sales, finance, service, legal and compliance.

A team shipping less code aiming clearly in the right direction will deliver more value to the business than a team with high throughput (features factory), yet little value is delivered to the customer. Even worst, delivering so many features of little value to customers ends up taking away from the product value because it typically impacts the user experiences, introduces complexity and friction, and often impacts the product quality and the team’s ability to execute fast. That’s right, all these new half-baked features are slowing the team down.

Final Thoughts

Your team needs you to take on these hard conversations around velocity. They may need your help to identify what is getting in their way to execute and ship product. But if you only focus on speed and doing more, you will likely miss the mark. you will ship output over outcomes. Outcomes matter a lot when it comes to delivering value!

Here’s another way of thinking about this and why execution alone is not going to get you to results.

Great execution x zero (poor strategy) is a waste of everyone’s time

Till next time!