DevOps: Slow Down to Go Faster

This common idea (search it) that sometimes you need to “slow down to go faster” has come up many times throughout my career. What it essentially means in the web development context is that we sometimes need to slow down releasing customer facing features in the short-term to focus on internal processes that will eventually make our velocity much greater in the longer-term. This may include increasing unit test coverage, automating builds, deployments, and other pure DevOps measures to increase the overall flow of work through the product team.

The easiest way to tell when you need to slow down to eventually go faster is when you are in manual firefighting mode. There always seem to be bugs to squash “real quick.” It feels like you're doing all you can do just to keep your head above water, and you're going at a breakneck speed, pulling all-nighters, and other heroics. All of this re-work kills your velocity against your actual product roadmap even though you are working around the clock. NOTE: this usually happens with an MVP product that is gaining traction and now has to become a “real” product.

If, instead, you simply paused work against the roadmap (slowed down) and focused on adding things like test harnesses, CICD pipelines, and build artifacts that are automatically done for you on every push to a remote branch, you’d get to a point where you could start developing tested code that works when you release it the first time. Instead of spending time re-working your new features (squashing bugs), you’ll be instead moving on to the next features in the roadmap and delivering more value to your users (which is the name of the game, of course).

After your overhaul, you’d continually raise the bar with higher test coverage percentages and automated end-to-end tests. Your code would be more robust and your stress-levels would decrease. This is all thanks to DevOps best practices and your willingness to “slow down to go fast”.