I worked on a project once where leadership celebrated every feature shipped, every deadline met, every sprint completed on schedule. The team was moving fast. Blazingly fast, by some measures. Every standup had good news. Every demo impressed stakeholders.

Eighteen months later, the codebase was a disaster. Adding simple features took weeks. Bug fixes caused cascading failures. New engineers needed months to become productive. The system that had been built so quickly had accumulated so much complexity and fragility that sustained progress became nearly impossible.

We usually describe this phenomenon as “technical debt.” It’s a useful metaphor, but one that’s largely misunderstood. Stakeholders hear “debt” and think it’s optional, deferrable, someone else’s problem. I’ve found a different framing that lands better.

In physics, there’s a distinction between instantaneous velocity and average velocity. Instantaneous velocity measures how fast something is moving at a specific moment. Average velocity measures displacement over time. That project had incredible instantaneous velocity. But we’d optimized for speed right now at the expense of mean velocity over time.

When you optimize for instantaneous velocity, you make decisions that maximize output right now. Skip the tests, we’ll add them later. Copy-paste instead of abstracting, it’s faster. Hardcode that value, we’re in a hurry. Take the shortcut through the module that wasn’t designed for this use case. Each individual decision is defensible in isolation. The feature ships. The sprint succeeds. The demo impresses.

But these decisions compound. Technical debt accretes like sediment. The shortcuts become load-bearing walls. Six months later, the “quick” approach has created so much drag that you’re shipping features at a fraction of your original pace. Your instantaneous velocity was high, but your mean velocity over any meaningful duration is abysmal.

Mean velocity matters more because software projects exist over time. A team that ships 10 features in month one and 2 features per month thereafter loses to a team that consistently ships 5 features per month. The math is obvious, yet I’ve watched smart people make this mistake repeatedly.

There’s a seductive quality to instantaneous velocity. It’s visible, measurable, and immediately rewarding. Stakeholders love it. Managers can point to graphs going up and to the right. Everyone feels productive. The costs are deferred and diffuse, while the benefits are immediate and concentrated.

Engineering leadership requires holding both timeframes in mind simultaneously. You can’t ignore short-term velocity entirely because shipping matters, deadlines exist, and businesses have real constraints. But you also can’t let the pressure of the immediate overwhelm the needs of the sustained.

The practical answer isn’t avoiding all technical debt. That’s unrealistic. The answer is having a deliberate strategy for managing it.

This means building in time for paying down debt, not as a reward for good behavior but as a regular part of how the team operates. It means being honest about when you’re taking on debt and why, rather than pretending shortcuts are free. It means periodically asking whether current velocity is sustainable or borrowed from the future.

On the project I mentioned, we never asked those questions. Every sprint planning session focused on what we could deliver in the next two weeks. Nobody asked what delivering at this pace would cost us in six months. By the time the bill came due, the team had turned over, leadership had moved on, and the engineers left behind were stuck maintaining a system that resisted every attempt to modify it.

If you’re in a leadership role, pay attention to the gap between instantaneous velocity and sustained velocity. A growing gap is a leading indicator of trouble. When your team is shipping fast but engineers are increasingly frustrated, when estimates keep growing for similar-sized features, when new hires take longer to become productive, you’re probably borrowing velocity from the future.

Sometimes that’s the right call. Startups racing to product-market fit might rationally accept technical debt in exchange for speed. But it should be a conscious choice with a plan for eventual repayment, not the default mode of operation that continues until the system collapses under its own weight.

The teams I’ve seen succeed over multi-year timeframes are the ones that optimize for consistency rather than bursts. They move at a sustainable pace, pay down debt regularly, and resist the temptation to sprint when a marathon is required. Their instantaneous velocity might look modest compared to teams optimizing for speed at any cost. But check back in two years and see who’s actually shipped more.