To scale up the system you’re changing, scale down the changes.
The bigger and more complex the system you’re working on, the more people involved, the more affect a change can have — the smaller each change needs to be.
When change is expensive, when it’s scary, don’t make fewer changes. Work to make changes less expensive (no matter how expensive that work is), so that everyone can make smaller changes, because tiny changes aren’t so scary.
Commit code sooner, work in small batches, get the code out there before the merge conflicts erupt. The State of DevOps Report for 2019 remarks that this helps in open source software. And that in business, a heavyweight change process makes everything worse, including the very risk it was supposed to reduce.
Economies of scale are reversed in software. One big change is more expensive than many small changes. To get bigger, get smaller.
(see: Kent Beck on Limbo and scaling software beyond current imaginings)