The magic in software products doesn’t happen in the software. It’s not the features, the code, or the data structures. Software doesn’t create any value in a staging environment. A product is only a product in the hands of its users. Products come alive in production.

In that way, a release is pure alchemy: we’re turning a bunch of bits into a valuable product.

The history of software releases has a very clear trend line. We’ve started with rare, quality-gated, humongous releases. There was a very official “Go/No Go” meeting for the gatekeepers and then the animal was released into the wild with a Big Bang. Over the decades, releases have become smaller and more common. Quarterly. Once every sprint. Multiple times per week. Continuous. Not every company is releasing that often and not every company should. The classic annual release, however, is going extinct.

The general mindset with regards to release frequency has changed for the better. What hasn’t changed, however, is the gatekeeping.

It’s not uncommon for production access to be restricted to a select group. Or even a single individual. It’s almost the industry standard that developers have to ask for permission from some higher-up to release a new version to the customers.

Why is that? It all boils down to a lack of trust.

When we only want to go live after the Product Manager gives her Go, that says something about the organization. It tells us that the team doesn’t own the product. It tells us that we believe our team is so far removed from the actual clients that they do not grasp the impact of the release. They are mindless cogs in a software machine operated by their management.

When only the senior developer has the power to go live, it tells us how the team operates. There is a hierarchy and no real knowledge sharing. Less experienced developers are seen as liabilities. Given the chance, they will just screw up the product. Juniors just need to code and the product needs to be shielded from them.

The thing with lack of trust is that it’s a kind of self-fulfilling prophecy. When juniors are never exposed to the production environment, they don’t get to grow and they will make dumb mistakes. When developers need the thumbs up from a “grown-up” to deploy their changes to production, they will not take responsibility for the outcome. Keeping your team away from the actual product is the best way to create a detached and disempowered feature factory.

The ideal product team owns their product. They know what they are building and who they are building it for. They are involved with their customers. They understand the impact of a release because they understand the product, not just the features, the code, or the data structures.

In that ideal scenario, all developers should be able to push changes to production when they see fit. There are plenty of exceptions and reasons why teams can’t operate at that level of maturity yet. Some regulated environments may have hard limits on production access. Some teams might just be too junior. But the ideal scenario should be the north star. In most cases, it just really is a lack of trust.

When we aim to build high-performing, engaged teams, this is a great starting point. We don’t have to release this change with a Big Bang. We can start small.

If your team has a single production gatekeeper, what’s stopping you from adding another one?