Momentum is 🔑
If you took physics in high school (or at least pretended to while copying homework), you probably remember this equation when doing an assignment:
p = m Ă— v
Momentum equals mass times velocity.
In software engineering, I think of mass as the quantity of work, and velocity as how fast it's being done. Momentum isn’t about cranking up one of these. You don’t win by doing everything, and you don’t win by doing one thing really fast if it’s the wrong thing. Momentum, is about from finding balance: doing the most meaningful work at the fastest sustainable pace.
Momentum matters because time is the most valuable resource in engineering (and in life, but that's a deeper discussion for another day). Not compute. Not headcount. Not even IC talent. You can always vertically or horizationally scale servers, hire more people (what a drag), or refactor technical debt. You cannot buy back lost time!
And.. unfortuntately.. engineering bleeds time.
Product managers want new features. Designers want UI/UX polishes. Customers want fixes. Infra wants Kube upgrades. Maintenance eventually comes to collect its tax. Meetings multiply and context switches pile up like dirty laundry. Suddenly, your week has flown by and the problems you set out to complete, the ones that actually add value and move the business forward, are sitting idle. All because they require uninterrupted thought which is becoming harder and harder to come by.
Momentum is how you fight back!
Momentum is what lets a team go deep instead of wide. Momentum is what lets you build the difficult things, the solutions that don’t come with tutorials, the abstractions that start to make sense after three botched attempts and the bugs that require running 6 different port-forwarded services locally. These problems and projects don’t get done via bursts of effort but continuous, sustained focus.
The harsh truth is that most engineering orgs don’t lose momentum because they’re slow. They lose it because they’re constantly stopping and starting. Every kickoff, every “quick sync,” every brainstorming session quietly eats away at your momemtum. Like a car, repeatedly accelerating and decelerating requires so much more energy. Especially if you are taking on a large quantity of mass (work).
Preserving momentum means being ruthless about your time. It means protecting focus like it’s the B bombsite on a match winning round of Counterstrike. It means batching bugfixes, minimizing parallel tasks, and being honest about tradeoffs. Sometimes the path of least resistance is okay. Sometimes saying no to good ideas so you can finish great ones wins. Accepting that some things will stay imperfect so the important things can exist at all.
Someone smarter than me once said, "perfect is the enemy of good". It's true..
Momentum also compounds. When a team is moving, decisions get easier. Incremental wins build confidence. Progress begins to be the norm. However, the opposite is also true. Stalled teams get cautious, over-discuss, nit-pick, index on edge cases, and drown in process trying to substitute motion with alignment. I hate that word, aLiGnMeNt.
Momentum is how progress truly gets made.
And in software, the distance between “this should work” and “this actually works at scale” is long, grey, expensive, and unforgiving. If you don’t protect your momentum, you’ll spend most of that journey idling, burning energy, going somewhere but nowhere at the same time. Then you're wondering why building hard things feels harder than it should.