Jason & Eiso talk about Velocity in Software Engineering, what it means, how to measure it, why data and metrics won’t magically solve all your problems, and what engineering leaders can do for their teams to go faster.
Here are a few of our favorite moments from the conversation
Engineering velocity is effectively this box in the middle of the mechanical parts that we have largely called CICD. With some inputs and outputs. I would expand that box from the moment a ticket gets picked up, the moment we decide to work on something in engineering, 'til it reaches that end user.
Certain organizations say they're agile, they'll say they're nimble, they'll say they're continuous, and what they have is a series of gated waterfalls.
You have to submit the PR, it's gotta get approved, it goes into CICD before or after, depending on which of the systems you're running. It goes from there, it gets set to pick up or automatically picked up depending on how sophisticated your system is. Then it goes to the next step, then the next step, then the next step. And each one of those steps either is a manual or automatic approval, but there's a some approval process to get this thing going.
The majority of tech companies today, even if they truly wanted to, can't actually automate everything because of compliance reasons. This is the part that we never speak about. If you are actually going through a SOC 2 Type II compliance or HIPAA there all of a sudden gates that you have to go through. And this means that some things will never become fully automated.
Stepping back, ****we gotta understand again what the goal is. The goal is to get stuff into customer's hands, and our goal is to get it into the customer's hands as quickly as possible, as safely as possible with as little bugs as possible. That's actually what we're trying to do. It's not, “we need to review each other's PRs and we need to have it go through the CI this way.” And- oh man, I could rant about that all day.
Everybody struggles because they assume that the moment we start measuring [velocity] and exposing the data to the engineering org, everybody all of a sudden is magically going to improve. And there's something that everybody misses, it’s that every engineering leader ever that I've come across anywhere is overwhelmed.
💡 Topic Explainers
💡 The Engineering Leader’s Process for Continuous Improvement
This mental model is mentioned by Eiso in the episode as an actionable way for engineering leaders to use metrics to continuously create positive changes in their organization.
You can read the full blog post on this process (which includes a real example) but here’s a quick rundown:
📕 Recommended Reading
What to dig deeper into engineering metrics and are not sure where to start? Here are a some books, blogs, and newsletters we recommend:
📘 Accelerate: The Science of Lean Software and DevOps
📄 9 Metrics Every Engineering Leader needs to Track
📄 What is Engineering Productivity & How do we Measure It?
Join the discussion and follow us on twitter @ devleadership_
Developing Leadership is powered by Athenian. We are introducing a winning approach to engineering metrics that can help you empower your teams to autonomously improve. If you want to learn more, go to athenian.com
Share this post