Building a High Velocity Engineering Culture
Because speed improves every other metric
At some point, a CEO will come to you and say:
“Things feel slow. We need an eng velocity metric.”
This is almost always well-intentioned. We should always want to move faster. And in practice, engineering will almost always feel slower than we want it to be—especially from the CEO’s perspective. That tension is normal and permanent. If it ever goes away, something is wrong.
It’s tempting to respond by looking for a single number that explains the feeling. I’ve read extensively on this topic—Abi Noda’s Engineering Enablement is a favorite—and the conclusion is consistent: there is no single metric that can definitively tell you whether an engineering organization is “fast.” Velocity matters, but it does not collapse cleanly into one measurement you can manage directly.
While there is not a single metric that exists, based on my research and hard-earned experience, these are the tools that I reach for when building a high velocity culture.
Talk About Velocity. A Lot.
Culture changes because people talk about something repeatedly and without embarrassment.
If you want a high-velocity engineering culture, velocity has to be discussed openly and often. Not as a threat. Not as a performance weapon. As a shared goal. People should hear it in planning meetings, retros, one-on-ones, and hallway conversations.
This starts with stating the obvious: of course we want to be faster. Of course there is room to improve. Saying this out loud regularly matters more than most process changes.
Wins should be loud. Shipping should be celebrated. Progress should be visible. This reinforces that velocity exists to help engineers do their best work, not to pressure them into cutting corners.
This also creates a shared language. Talking about speed should not feel like an accusation or a critique of individual engineers. It should feel normal, neutral, and collective—something the team owns together.
As a side effect, this helps with managing up. When velocity is a consistent topic, CEOs and execs feel that it’s being actively worked on. They stop asking for a single magic metric and start trusting the system.
Identify What’s Slowing You Down
You cannot make a team faster if you don’t know where time is being lost.
Some sources of drag are technical. Builds are slow. Tests are flaky. Deploys are fragile or mysterious. Engineers are usually very aware of these.
Others are organizational, and these are often harder to surface. I had a CTO friend recently realize that one reason teams were reluctant to ship early was that the ops team would yell at engineers any time a change was made without weeks of advance notice for training. From the outside, it looked like a lack of urgency. In reality, it was a rational response to punishment.
A high-velocity culture makes it easy to surface this friction. The cost of reporting drag should be close to zero; otherwise, people simply won’t do it. Engineers should be able to say, “This slowed me down,” without defensiveness or fear of consequences.
One simple mechanism is a lightweight velocity retro at the end of a project. Ten minutes. No slides. Just a central place where engineers can drop a list of everything that made progress slower than it needed to be. We especially want the embarrassing stuff, so we have the opportunity to fix it.
This process must be continuous. If friction is only discussed occasionally, it will compound faster than you can remove it. Teams that feel fast are not the ones without problems—they’re the ones that surface and address them quickly.
Measure What Slows You Down
While measuring velocity directly is close to impossible, measuring the things that slow you down is usually straightforward.1
Start with the inner development loop: edit, build, test. This loop is sacred. If, after each change, an engineer has to wait long enough that their attention drifts, velocity is already gone.
Build time, test time, and deploy time in CI matter more than almost anything else. If this loop feels slow or unreliable, nothing else in the system will feel fast.
Beyond the core loop, there are other common sources of measurable drag:
Code review turnaround time
Time to deploy (if deploying is slow, people do it less, and iteration slows with it)
Time to first deploy
Flaky tests and intermittent failures
Hard-to-read code or missing patterns
For engineering work, having a concrete quantitative metric to ratchet down is powerful. When you’re confident something is slowing you down, measure it and reduce it. You may not be able to measure velocity directly, but you can measure drag.2
Build a Productivity Baseline (Carefully)
You need a productivity baseline.
Not because maximizing output is the goal, but because without baseline data, the right conversations don’t happen. “It feels slow” is not something you can debug. Concrete data gives teams a shared starting point for understanding what changed and why.
Story points (or an equivalent) are sufficient for this. They don’t need to be precise; they need to be consistent. Shipping roughly 20 points one sprint, 22 the next, and then 15 after that is enough to ask useful questions. Without that data, those questions simply don’t happen.
Each team should also be using a productivity tool to collect this data. Tools like DX, LinearB, Jellyfish, and similar systems are best thought of as instrumentation. They surface patterns around PR throughput, cycle time, and deploy frequency that are otherwise hard to see.
The caution is in how these tools are used. The moment a baseline becomes a target, behavior will shift to optimize the number instead of the system. That’s the predictable Goodhart’s Law failure mode.
This is where the earlier, more qualitative cultural work matters. If you actually did the work to build a culture that genuinely cares about velocity, this data becomes empowering. Teams use it to be curious about their own bottlenecks and improve without being told what to do. If you skipped that part and jumped straight to dashboards, the same data will feel like overhead or surveillance—and will be treated accordingly.
Holding Leaders Accountable for a Velocity Culture
Velocity does not sustain itself. It has to be actively propagated.
Leaders are responsible for keeping velocity present in how work is planned, discussed, and reflected on. That means making speed a normal topic of conversation—not a reaction to pressure, not a postmortem after something goes wrong, and not a proxy for performance management.
For any meaningful project, leaders should be pushing on timelines, not to create stress, but to surface assumptions. How long do we think this should take? Is that timeline conservative? What would have to change for us to be more aggressive? Asking what it would take to do the work in half the time is a useful forcing function. Not because it’s realistic, but because it reveals where scope, process, or sequencing can be rethought.
While there’s no clean way to roll velocity up into a single aggregate number, teams that care about velocity develop a strong intuition for it at the project level. “This used to take us a month, now it takes a week.” “Why is it so hard for us to upgrade to the next version of Postgres?” It is much easier to have a quantitative intuition for what fast looks like at a project level. Of course it’s not the magic eng velocity number that the CEO asked for, but sampling how long individual projects take can help build up data to better understand velocity.
That intuition only forms when leaders consistently reinforce it. By creating space for teams to notice when work feels slow, when progress stalls, or when a change meaningfully compresses timelines, leaders turn those observations into shared context. Retros surface what sped things up or slowed them down, and follow-through removes friction.
It’s intentional that this section keeps saying leaders. This work can’t be centralized. A VP of Engineering can’t be everywhere, and shouldn’t try to be. Velocity culture spreads through leaders throughout the organization. While this should be a core responsibility of engineering managers and staff engineers, there are many kinds of leaders in an engineering organization, and all of them should be accountable for nurturing a culture of velocity. In engineering, this looks like engineers jumping into reviews unprompted, fixing flaky tests they didn’t write, improving build scripts they don’t “own,” and noticing when someone is stuck before it becomes a ticket. You see this same pattern in elite sports teams, emergency rooms, trading floors, and flight decks — places where collective tempo matters more than individual heroics.
A Note on AI and Velocity
It would be strange to write about engineering velocity in 2026 without acknowledging that AI is already changing how software gets built.
This piece is intentionally not about AI tactics. That’s a long conversation unto itself, and this post is already much longer than our median article. What matters here is that teams with a strong velocity culture naturally start asking better questions about how AI fits into their work.
They don’t ask, “How do we mandate AI usage?” They ask, “What’s slowing us down, and can AI remove it?” Can mundane work be turned into background tasks that generate PRs while engineers sleep? Can reviews, refactors, or migrations be accelerated without increasing risk? Can development environments be reshaped so that product requirements flow directly into agents that can build or scaffold features themselves?
Consider this a teaser on some of the most interesting ways that AI can accelerate engineering teams.
Engineers Need to Ship
I worry that this focus on velocity can sound crushing at first. That reaction is understandable. Velocity often gets conflated with grinding harder. They are orthogonal. This approach isn’t about grind; it’s about intentional growth and improvement.
Is it intense? Yes. When it’s working, people are locked in and working hard. Great engineers have a deep-seated desire to ship great things. Velocity alone won’t fix poor compensation, bad management, or a weak mission — but without velocity, even those rarely hold great engineers for long.
A healthy velocity culture creates an environment where engineers can work on important problems, move with urgency, and see their work land in the world. Over time, that turns velocity from a management concern into a powerful part of your retention strategy. A high-velocity engineering culture builds a virtuous cycle where it helps grow your business and attract and retain talent.
Credit to Engineering Enablement for introducing me to this idea.
Extra points for simple metrics. You want something where it’s obvious how changes engineering can make will move the number. The more synthesized a metric becomes, the harder it is to see that connection, and the less effective it is at focusing execution.