Sunday 23rd March 2026

Why deploying multiple times a week isn't a panacea.

I have worked in companies with quarterly release cycles and companies who deploy code to production multiple times a day. You are led to believe (especially in agile transformation circles) that deploying more often is the key to success. Take your dusty old on-prem server boxes, throw them in the nearest skip, chuck all your stuff in AWS and you're on your way to more agility. They're not wrong, being able to deploy frequently is a good thing and almost invariably better than not being able to deploy more often than once a quarter, but it doesn't always mean you're delivering more value.

I generally dislike the "delivering value" spiel that people who sell you SAFe courses have flooded the software development industry with, but even at teeny tiny startups who deploy code multiple times a day, it doesn't mean you are doing better from a product perspective if you are deploying more frequently. This may seem backwards, because the less time to wait until users can use the thing you built is a good thing, but it just highlights a bigger, more fundamental problem: building the right thing is REALLY HARD. (You don't see the SAFe guys selling a course on that, do you...).

It is much, much easier for me to provision infrastructure that allows me to deploy a web application within 3 minutes (might write about that next) than to bank on delivering something that markedly changes a given outcome in the next 3 months. There are plenty of frameworks and models, but famously they're all wrong, and in my experience building the right things is the result of disciplined experimentation, small changes, and a leadership team who are willing to let you work at something for more than 5 minutes before changing their mind.

Don't get me wrong, being able to deploy frequently is a great thing when it comes to disaster recovery, rollbacks, and other things that require a quick fix, but it does comparatively little to help product managers deliver the right thing, and often just enables the dreaded "feature factory" and delivering the wrong thing faster. I like to remind myself that we are not here to deliver the wrong thing faster, and "what is the right thing?" is hard to figure out, but I guess that's the job.