During a recent episode of Developing Leadership, Jason Warner (Former CTO @ GitHub) and I had a fantastic discussion on one of the hottest topics in our space: engineering velocity.
We delved deep into the various patterns that can slow down engineering orgs and shared our tips on how you can improve your systems' flow. This quickly became one of our most listened-to episodes, so I decided to put the learnings together.
👉 You can listen to the episode here
Today, I’ll share some of the key lessons from my chat with Jason, exploring engineering velocity in depth, including how to measure it and how to tackle bottlenecks that arise as your organization scales.
At Athenian, we’re on a mission to help engineering organizations continuously and autonomously improve, and measuring velocity is often the first step toward achieving your goals.
So, let’s get started.
What is Engineering Velocity?
What’s your goal as an engineering organization? It’s to get your product into the customer’s hands as quickly as possible, as safely as possible, and with as few bugs as possible.
💡 Engineering velocity is a measure of your organization’s ability to take an idea and get it all the way out into customers’ hands.
From the moment a ticket gets picked up to the moment we decide to start working on something, ‘til it finally reaches your end user. This whole process, from beginning to end, is engineering velocity.
👉 In a perfect world, at the touch of a button, you’d instantly release your code to production with all tests passed and everything working perfectly.
An organization with a perfect engineering system like this in place would have achieved 100% engineering velocity. So fast, it’s basically instant. Yet most, if not all, of the engineers I talk to struggle with velocity. Things simply take too long.
Why do Engineering Orgs Struggle With Velocity?
Organizations claim to be agile. But in many cases, what looks like an agile workflow is actually a series of gated waterfalls. You have to submit your pull request. It has to get approved. Then it has to go to the next step. Then the next. And then the next again.
Each one of these steps will either be manual or automatic. If they’re automatic, they’ll be faster.
👉 But the majority of tech companies cannot automate too much, even if they wanted to, for compliance reasons.
🔐 SOC 2 Type II compliance and HIPAA are just some of the major hoops organizations must jump through, and this just means that some things can never be fully automated.
Organizations struggle with velocity because as they scale, they get overwhelmed.
Too many pull requests, too many steps, so much compliance, and very little automation. No wonder products take so long to get to market.
How Can Engineering Orgs Improve Velocity?
Helping engineering organizations improve is my jam, and, most of the time, working towards continuous improvement starts with measuring engineering velocity.
But it’s one thing to measure velocity. What really makes a difference is what you do with the metrics.
Everything won’t magically speed up once you start measuring velocity. You’ve got to look for your bottlenecks. What’s taking the longest, and why?
1. Rediscover Teamwork
Imagine an engineering team with a cycle time of 36 hours.
💡Cycle time – the amount of time it takes a ticket to go from initial commit to production.
You drill down into the data to get visibility into the different codebases this team’s contributing to. And you see, there’s a cycle time of 12 hours on one code base but four days on another. Why is the cycle time on one code base significantly larger than the cycle time on another?
Investigate this bottleneck, and you’ll probably find that the team is spending a lot of its time waiting. They’re waiting on a review or on approval for a merging process.
As your organization scales, it won’t be the person sitting on the other side of the office who approves your code. It will be someone from another team. And that team will have its own problems to deal with. How likely is it that they’ll prioritize your code?
One of Jason and I’s biggest frustration is why we still teach engineers that their individual tasks take priority over everything else.
When did we stop working together towards achieving a shared goal?
2. Make Time For the Review Process
When you first start measuring engineering velocity, you’ll most likely find that the review process is acting as a major bottleneck.
Engineers submit their PR for review, then immediately move on to their next task. They have to. Because when your engineering organization scales, everyone’s workload is going to scale too. But if every engineer takes this approach, then who’s going to actually do the reviews?
The solution to this? 👉 Make time for reviews.
Set aside some dedicated time each week for each team and each engineer to focus solely on reviewing PRs.
This could just be for three hours or so on a Monday afternoon. Really, no time at all. But make time for reviews, and you’ll probably see your engineering velocity improve.
Who Does The Reviews?
Reviews shouldn’t fall on the shoulders of one engineer or even on the shoulders of a handful of engineers. Taking this approach would likely create a bottleneck in itself.
When assigning people to reviews, go for a balanced approach.
It could be a rota system or a round-robin. Whatever it takes to ensure that everyone does their share of reviewing.
You could also invest in some automated review processes for certain types of PRs. As I said earlier, some things will never be automated for compliance reasons. But the more processes you can safely automate, the more you’ll see your velocity speed up.
3. Setting Good Goals
What sort of goals do you set in your engineering organization – for your engineers, for your products, and for your organization as a whole?
You might define a date for when you want to release a certain feature. But once you start measuring velocity, it’s much better to set goals around the things you want to improve.
Constructive goals might include:
- Reducing your cycle time.
- Reducing your tech debt.
- Improving the review process.
- Improving your bug prioritization process.
Set these goals and let everyone know about them.
You might see people change processes, hold meetings, do retrospectives, and just generally work on improving your CI system.
💡 Setting clear goals for continuous improvement gives your engineers permission to address the frictions that bother them.
A Mental Model For Continuous Improvement
Engineering leaders can help their organizations improve their velocity by adopting this process for continuous improvement.
- Identify what you want to improve.
- Discuss and communicate with the relevant people.
- Decide what you’re going to do.
- Align your decisions across your entire organization or to the part of the organization that applies. The bigger your organization, the more time you’ll spend discussing and aligning. Define the goals, KPIs, targets, and metrics you want to measure in the end.
- Act. Ensure that stuff gets done.
- Measure the impact of what you’re doing.
And repeat.
Because the clue’s in the name – continuous improvement is continuous.
Be honest: are you doing this? Are you identifying what’s helping things deliver better? Are you identifying how to create a better developer experience? Where do you need to be better?
.png)
I wrote a full guide to the engineering leader’s process for continuous improvement, which you can find here.
Your mission isn’t to measure your velocity. Your mission is to improve it.
Measuring your velocity will give you a good understanding of the various bottlenecks that are slowing down your cycle time. And as your engineering organization scales, you will encounter these bottlenecks.
When your engineering velocity is slow, everyone across your whole organization will feel frustrated. But with the right tools, the right people, and the right mindset, you can streamline your processes while making life better for both your developers and your end-users
Athenian can help you increase your organization's engineering velocity by giving you end-to-end visibility of your software delivery pipeline. So you’ll know where to prioritize to improve velocity and quality and align your teams 👉 find out more!
