The Physics of Velocity

In the startup world, "move fast and break things" was the mantra for a decade. It captures the excitement of software engineering—the sheer rush of shipping code. But as I’ve transitioned into the Principal Engineer role, looking at systems that span hundreds of engineers and multi-year horizons, my relationship with speed has changed.

I’ve come to realize that velocity is not speed. Speed is a scalar quantity—it's just how fast you are moving. Velocity is a vector: it is speed plus direction.

If you are sprinting at a record pace but running in the wrong direction, your velocity relative to the goal is negative.

To understand true engineering velocity, we have to look at it like athletic training. You can muscle through a deadlift with poor form and get the bar up. You might even hit a PR. But that inefficiency costs you energy, risks injury, and limits your long-term ceiling.

In software, "poor form" is the friction between intent and execution. It is the clutter in the garage you have to navigate before you can even start building the table.

Here is my perspective on the "proper form" of engineering velocity, built on five critical pillars.

1. Proper Alignment: The Vector of Intent

Without proper alignment, effort is wasted through inefficiency. In a large organization, the Principal Engineer’s job is to bridge the "chasm between macro-level business strategy and ground-level engineering reality".

If the team doesn't understand the "why," they are just typing fast. Alignment isn't just about increasing productivity; it’s about reducing the cognitive load required to make a decision. When a team is aligned, they don't have to stop to ask if they should optimize for cost or latency—they already know the strategic roadmap.

2. Proper Space: Decluttering the Mental Garage

Imagine trying to build a cabinet in a garage where you have to step over a lawnmower and move three boxes just to reach your saw. You can do it, but the friction cost is incurred every single time you make a cut.

In engineering, "space" is the environment we work in. It is the architectural clarity. When we allow systems to decay, we clutter the workspace. A key part of my role is "systematizing technical debt management". We have to clear the floor. If engineers are constantly fighting the framework or navigating spaghetti code to ship a feature, our velocity is suffering, no matter how hard we work.

3. Proper Tools: Governance as an Accelerator

Tools are not just IDEs or CI/CD pipelines. In the context of a Principal Engineer, tools are the mechanisms of decision-making.

I rely heavily on Architecture Decision Records (ADRs). These aren't just paperwork; they are tools that "streamline organizational decision-making". They prevent the team from re-litigating the same arguments every six months. A proper toolset allows a Senior Engineer to make a Director-level decision without needing a meeting, because the guardrails and context are already in place.

4. Proper Methodology: Rhythm over Rigidity

Methodology isn't about red tape; it's about rhythm. It’s the difference between flailing and flowing.

Inefficient teams rely on "heroics"—the "Solver" archetype who bounces from fire to fire. While that feels like high velocity because it’s high adrenaline, it’s actually a symptom of system failure. True velocity comes from "Quarterly Alignment" and sustainable rhythms. It’s the boring consistency of a well-oiled machine that allows us to ship safely at scale.

5. Proper Mindset: Confidence is Relaxation

This is the most counter-intuitive lesson I’ve learned: Confidence is relaxation.

Watch a master craftsman or an elite athlete. They rarely look hurried. They look fluid. Tension is a sign of uncertainty. When you are tense, you make mistakes, you introduce bugs, and you burn out.

In software, a "relaxed" architecture is one that is resilient. A "relaxed" engineer is one who trusts the testing infrastructure and the deployment pipeline. We move faster when we aren't terrified of breaking production.

The Principal Perspective

Velocity is not about frantic motion. It is about moving with clear intentions.

As we scale from individual contributors to organizational leaders, our focus shifts from "doing" to "enabling". We stop trying to run faster ourselves and start focusing on removing the blockers for the 50, 100, or 400 engineers around us.

We clean the garage. We align the vectors. We perfect the form. And then, we watch the velocity fly.