Velocity isn’t chosen. It’s purchased. And the price is set by the friction of reality. In high school, velocity is beautifully simple:

velocity = displacement ÷ time

However, in systems we create:

Real-world progress is messy, expensive, and surprisingly nonlinear.

Teams don’t move at the velocity they want — they move at the velocity the system allows. To model that velocity in a way that allows us to see many variables in one short-hand place, we need a systems equation.

The 3 Taxes Systems Pay

Systems—technical, human, organizational—have at least three multiplicative drags:

1. Resistive Force (F)

Everything pushing back on progress:

• tech debt
• approvals
• market friction
• legacy architecture
• slow tools
• bandwidth constraints

The “gravity” of our systems.

1. Tortuosity (τ)

The wasted distance between “start” and “done”:

• rework
• unclear requirements
• scope churn
• loops in decision-making
• detours caused by misalignment
• unproductive meetings

The straighter the path, the lower τ. Many teams zig-zag without realizing it.

1. Internal Inefficiency (η)

How much energy is lost internally:

• context switching
• poor tooling
• unclear communication
• architecture that fights you
• low-leverage effort
• distractions and interrupts
• the distance between GPUs and memory

If η = 0.5, half the effort may become heat.

A Simple Equation for Realized Velocity

Here’s the model:

v = E ÷ (F × τ × (1/η) × t)

Where:

• v = real velocity (desired/useful progress per unit time)
• E = energy applied (effort, compute, budget, focus)
• F = resistive force
• τ = tortuosity
• η = internal efficiency
• t = time window

This is a systems equation—describing how organizations, teams, and technologies actually move.

An Engineering Example

Think of an engineering team shipping a feature.

E = their hours, focus, compute, attention F = tech debt, dependencies, approvals, tooling τ = rework cycles, requirement churn, unclear decisions η = quality of architecture, tests, alignment, tooling t = the release window v = actual useful progress per week

You can double E (work harder!) But if F, τ, and (1/η) are high, velocity barely moves. In addition, in some systems F, τ, η and t react non-linearly to increased E.

That’s why “just go faster” can fail. You can’t shout your way around systematic constraints.

Why This Matters Right Now

For the last decade, significant progress, scaling "laws", has been achieved by cranking up E — more compute, more hours, more GPUs, more everything.

However, constraints are seemingly everywhere. While amazing refuctions in F, τ, η and t, have been realized, E is going up faster - you might even say: "to the moon!".

It is hard to image a state of the world where incredible engineers are not making Black Swan step-functions in F, τ, η over the next decade, even if the only option is to run data centers in space / on the moon.

Potential velocity may be dictated by E, however sustainable velocity is in the domain of F, τ, amd η.

The Takeaway

• Velocity is not selected. Velocity is earned.

You increase velocity/progress by spending energy wisely, and by removing every drag factor quietly multiplying in the denominator.

If you want to go faster: Don’t demand more effort. Remove more friction.

Read more at this link.