What the science of high achievement tells us about shipping software between Series A and Series C, and the one number most founders can't answer.

Start with the question that matters most. How fast does your team actually ship?

Not how fast it feels. Not the story you tell your board. The number. The median time between a developer finishing a change and your customers using it. Research on achievement points to one unglamorous habit shared by the people and teams who improve fastest: they measure the thing they want to get better at. And here is the encouraging part. Most teams at your stage genuinely have no idea what their number is. That is not a failure. It is an opportunity you haven't opened yet.

Why velocity is a grit problem, not a talent problem

The most surprising finding in the study of grit, the combination of passion and perseverance toward long-term goals, was how little raw talent predicted success once effort was accounted for.¹ The idea is captured in a simple equation: talent times effort produces skill, and skill times effort produces achievement. Effort, in other words, counts twice.

Your delivery pipeline works the same way. You almost certainly hired talented engineers, and that is rarely the constraint at Series A through C. What separates the teams that pull away isn't brilliance in a burst. It is the steady, deliberate compounding of small improvements to how work flows from idea to production. That is effort applied to a system, over and over, and it counts twice: once in the features you ship this quarter, and again in the velocity you carry into next year.

The research bears this out at scale. DORA, the largest ongoing study of software delivery, now spanning more than a decade and tens of thousands of professionals, has shown repeatedly that speed and stability are not a trade-off. The teams that ship fastest are also the most reliable.² The old founder intuition that you must choose between "fast and sloppy" or "slow and safe" is, empirically, wrong. As one engineer put it, the real trade-off over time is between better software faster and worse software slower.³

The four numbers that tell you almost everything

You don't need a dashboard with forty metrics. The DORA program distilled software delivery down to a handful of measures, and four of them will tell you most of what you need to know about your team's velocity and health:²

• Deployment frequency: How often you push changes to production.
• Change lead time: How long from a committed change to that change running live.
• Change fail rate: The share of deployments that need an urgent fix or rollback.
• Failed deployment recovery time: How quickly you recover when one does break.

The first two describe your throughput, your pace. The second two describe your stability, whether that pace is safe. Look at all four together and you can place your team, honestly, somewhere on a spectrum. It runs from teams deploying on demand many times a day with a change failure rate around five percent, all the way down to teams deploying once every few months and losing days to recovery.⁴

A word of caution matters here, because measurement done poorly does real harm. A metric that becomes a target stops being a good metric. That is Goodhart's law, and the DORA researchers name it as the first pitfall for a reason.² If you tell your team "everyone deploys five times a day by Q3," you will get gamed numbers and burned-out people. The point of a benchmark is not to crack a whip. It is to give you an honest starting line.

Why your stage is exactly the right time

Between Series A and Series C, you are living through the most consequential transition in an engineering org's life. At Series A you had a handful of engineers who could hold the whole system in their heads. By Series C you may have crossed a hundred, with teams that have never met shipping into the same codebase. The habits that felt effortless at ten people quietly break at fifty, and the failure is rarely loud. It shows up as a lead time that has crept from hours to weeks while everyone was heads-down.

This is the moment deliberate practice matters most. Research on expert performance shows that improvement comes not from mere repetition but from focused practice against a clear target, with feedback, at the edge of your current ability.⁵ A team without a velocity baseline is repeating, shipping and shipping and shipping, but it isn't practicing deliberately, because it has no target and no feedback loop. A baseline gives you both.

You can't improve at what you refuse to look at. And you can't look at what you never measured.

What to do with the number once you have it

Here is the sequence worth following, and it mirrors what DORA recommends for teams starting out.² First, set a baseline. Find out where you actually stand on those four measures, no judgment. Second, have a real conversation with your team about where the friction lives, because they almost always know. Third, commit to improving the single biggest bottleneck, not all of them at once. Then do the work, check your progress, and repeat. It looks almost too simple, and that is the point. Grit is rarely dramatic. It is the same quiet loop, run with patience, long after the initial enthusiasm fades.

One caution is worth naming as you adopt AI tooling across your stack. The most recent DORA research found that while AI meaningfully boosts individual productivity and satisfaction, it can also strain delivery stability and throughput if the fundamentals, small batches and solid testing, aren't already in place.⁶ That is more reason to know your baseline before you change the inputs. You can't tell whether a new tool helped if you never measured the before.

Consider one last piece of encouragement, the kind worth offering anyone chasing a hard, long-term goal. The teams that end up in the top tier didn't get there because they were faster people. They got there because they were willing to look honestly at an uncomfortable number, and then show up, again and again, to move it. That willingness is available to you today. The only thing standing between you and it is a baseline.