Let’s talk about software releases — and how almost no startup gets it right.

What is a Release?

The problem starts here. To many developers, dev managers, product owners, and C-level stakeholders, a release means that the code for a given feature or product is complete and ready for production use. This is simply wrong.

Code readiness is not release readiness.

Think of the finished code as an airplane sitting on a tarmac. This is your shiny new product that you immediately want to ship and start making money with.

• Who is going to pilot this thing? No one knows to fly it. (Internal Training)
• What do you train the future pilots with? (Technical Documentation & Learning)
• Who are your ideal buyers for this plane? why and how does it cater to their needs specifically? (Marketing)
• How are your agents going to sell this plane to commercial flight businesses? (Sales Playbook)
• Has it actually ever been flown before? Stress tested in adverse conditions? What are its limitations? (Quality Assurance)
• How much should this plane sell for? Is there a basic and premium package? And what’s it called, anyway? (Product Marketing)
• Who gets called if it breaks and how long is its warranty? What if the customer wants unique modifications — are they possible? (Support)

When you go live with a new product or feature without giving supporting roles proper time to prepare for launch, you are hurting everyone involved. The customer becomes a guinea pig for a shoddy product. Support and implementation experts are forced to bare the brunt of customer frustrations at all hours of the day due to “fires” that must be put out. Marketing and product marketing experts have to scramble to align field teams on messaging, price points, and feature names…

… it goes on and on.

The cost of hastily pushing out a release on code alone is immense, and if your product can fail in ways that are catastrophic to your customer’s lives or bottom-line, you won’t make it to Series B funding — let alone IPO.

A release is a product event made possible by the completion of a cross-departmental project, launched only when all contributors are ready.

The Release Management Layer

Who decides to release if not the engineers? This puzzles many startups. Here’s my answer: the release manager.

Having a dedicated release manager provides clear ownership of a release without departmental bias. Performing the job requires embodying cross-departmental communication — which in turn empowers teams to trust asynchronous sources of truth, as the release manager owns these pieces within the release management layer.

The release management layer is a cross-departmental body where engineering, marketing, product marketing, support, and sales come together to check-in on the roadmap and signal baton-passing. This is similar to a “scrum of scrums” situation — it is high level and does not dictate or micromanage the workload or workstyle of the various teams across the company.

When all relevant stakeholders report a green light to the release management layer, the release manager launches the product.

That’s it. You’ve mastered software release management. So then why’s this an issue worth writing about?

Why the release management layer rarely exists

Startups tend to live and die by these mottos:

• “Perfect is the enemy of done.”
• “Don’t ask, just go do it.”
• “Everyone wears many hats.”

This outlook works in the beginning — in fact, it’s usually the only way to start most endeavors. But this wild-west execution strategy does not scale. The original team that launched the startup is used to ultimate power, without restraint, and little-to-no consequences for iterative failure. This is the team that wants to stick around and reap the IPO rewards, level up their career to departmental leadership, and reminisce about when you were all just selling vaporware.

This group tends to be your biggest blocker in evolving internal processes. Although they quickly identify the need for domain specialists (in legal, marketing, IT, content, and so on) they are often unwilling to relinquish control. They don’t know you as well. You didn’t build this thing — you weren’t there.

At its worst, this can look like hiring a head of product, or a VP of marketing, only to “forget” to include them in critical business meetings. The original team has satisfied the advisory board’s requirement of bringing in an expert, only to leave them out of the discussion.

Every other supporting role that reports up to these powerless figure heads are also, in effect, cut off from impacting meaningful change unless they realize (as they often do) who is really in charge.

Congratulations, you’ve now created a toxic political startup that has tightly centralized power and no real accountability associated with it.

It’s important to understand that this is no one’s fault directly. This is a very common occurrence that requires vigilance and mindfulness to avoid.

How to introduce structure to chaos

My experience leads me to believe that the only way to resolve this problem is to address it in a public forum instead of privately with your boss or their boss. If you want to champion release management and empower domain experts to take full control of their responsibilities, the discussion cannot happen in a private chat. It gets forgotten, dismissed, and shifts the burden of change to someone who may not feel comfortable challenging the existing power structure.

Putting forth reasonable systematic improvements and shining light on cross-departmental pains in a public forum allows others a chance to either support you or sit with the problem themselves. Over time, you’ll find that others begin to parrot the same suggestions:

• “We need to improve our release management”
• “How does this project advance our mission?”
• “We need to align more cross-departmentally”
• “Where can I find our playbook on…”
• “What’s our mission statement and brand identity?”
• “Who owns this?”
• “This request isn’t in the agreed scope for this quarter’s goals, why is it considered urgent?”

It’s also much harder for leaders to dismiss reasonable critiques that happen in public. Making leadership explain their business decisions, especially when made in spite of expert consultation they asked for, isn’t rude or cruel. It’s as important to them as it is to you — after all, over 70% of startups fail. That’s no secret.

Initially, this public forum can be as simple as a large slack channel. It could be a line item during the company all-hands. Eventually, it may evolve into a monthly cross-departmental meeting. Over time, the goal is to centralize the authority to launch a product outside of your standard departments while simultaneously giving those departments autonomy to execute their work using whatever tools or processes they know to be best.

The public forum evolves into the release management layer.

Now you know how to introduce release management and why the problem occurs so often.

If you are in charge of your own startup, or a significant player in one’s early stage, you can manifest this infrastructure of healthy criticism and unbiased release oversight before it becomes an deeper problem. For everyone else, expect this change to take 6+ months. Your public advocacy will infect and empower other players to chime in and slowly change the course towards a healthier startup culture with better ownership and smoother software releases.