Can a software team increase speed AND stay stable
There are some physical laws which can be applied on software development as well.
Can a software team increase speed AND stay stable?
Yes, but just like in physics, you have to engineer for it deliberately. Speed alone destabilizes. The teams that achieve both aren’t going faster carelessly, they’ve built the equivalent of downforce and gyroscopic resistance into their process.
The Physics Mapped to Software
Resonance / hitting a natural frequency Every team has a “natural frequency”, the sustainable pace at which communication, review, testing, and deployment can cycle. If you push velocity past that rhythm, you hit resonance: bugs amplify, tech debt compounds, and small coordination failures cascade. This is why crunch periods often cost more time than they save.
Control lag The faster a team ships, the faster feedback must arrive. If your QA cycle takes 2 weeks but you’re deploying daily, errors are already deep in the codebase before correction kicks in. CI/CD pipelines, automated testing, and monitoring are literally control loop tightening, reducing the lag between error and correction.
Nonlinear effects / turbulence Small teams at low velocity behave predictably (laminar flow). Scale the team or the speed, and you get turbulence: miscommunication, merge conflicts, duplicated work, unclear ownership. [[Conways Law]] is essentially a description of this turbulence.
What Is the Inertia of Software Development?
Inertia is what resists change in direction, it protects momentum but makes pivoting costly.
In software, inertia is:
- Tech debt — accumulated shortcuts that resist refactoring
- Existing architecture — the codebase’s structure pulls new features toward old patterns
- Team habits and culture — how people actually work, regardless of process documents
- Stakeholder expectations — commitments already made constrain future decisions
- Legacy dependencies — libraries, APIs, infrastructure you can’t easily replace
Good inertia (like a gyroscope) keeps the team from being destabilized by every new idea or pivot request. Bad inertia is the same force working against you when you need to change direction.
What Is the Downforce of Software Development?
Downforce pushes a car into the road at speed, it doesn’t slow you down, it keeps you grounded as you go faster. The faster you go, the more it helps.
In software, downforce is:
- Automated testing — the faster you ship, the more it protects you
- Continuous integration pipelines — catches instability before it reaches production
- Observability and monitoring — tells you immediately when something is wrong at speed
- Clear documentation and ADRs — keeps decisions grounded in reasoning, not memory
- Strong team communication rituals — standups, retros, design reviews that scale with pace
- Domain expertise — a team that deeply understands the problem space handles speed without chaos
The key insight: downforce only works at speed. A team doing one deploy per quarter doesn’t need a sophisticated monitoring stack. But a team deploying 50 times a day absolutely does, and that stack is what enables the 50 deploys to be stable.
The Fighter Jet Warning
Remember: fighter jets are intentionally unstable for maximum agility, kept flying only by constant automated correction. Some startups operate this way, moving so fast that only heroic individual effort keeps things coherent. It works, until the “computer” (a key engineer, a process, a funding runway) disappears. Then it crashes fast.
The sustainable answer is to run your software development more like a well-engineered race car: fast by design, with stability built into the structure, not bolted on as an afterthought when things start wobbling.