Why Early Releases Often Fail in Multi-Team Organizations

At best, it means:

What’s the earliest reduced version we can put in front of real customers to validate against something we actually want to learn?

At worst, it’s just a date and an announcement with nothing clearly scoped behind it, so that gap needs to be closed before anyone starts building toward it.

That’s where things usually start to go wrong.

Business, product, and engineering often mean different things by “early release”

Once one customer flow is split across several teams, an early release becomes real coordination work.

Someone has to lead it end to end, and that usually falls to no one. The reduced scope drifts and nobody is coordinating the whole release. With each new team that holds a certain piece of the project, coordinating them gets harder. The fix is good management, and it requires someone to actually lead the release.

Part of the trouble is that the same words mean different things to different people who are, of course, the part of the same meeting. When the business asks for an early release, it usually means a reduced scope of something, made to be more of a barebones product than a full-sized one. This is something that’s enough to validate assumptions and deliver value while the rest is still being built. 

To most engineers, “done” means complete, so “early release” gets heard as “the whole thing, but fast.” Put an MVP, the smallest version that tests your least-sure assumption in the mix alongside full GA, the finished product for everyone, and one phrase is now pointing at three different targets.

Nobody draws the line between them, so scope drifts toward GA by default: a team builds one target while the plan assumed another, and that drift is what sinks these releases. 

How one customer journey becomes nobody’s problem 

Multi-team releases break along a predictable line, and it was mapped a long time ago. In 1968, Melvin Conway published a paper called How Do Committees Invent? with an observation that later became known as Conway’s Law. The law states that organizations that design systems are constrained to produce designs that copy their own communication structure.  

Applied to a release, it predicts the break before anyone writes code: split one customer journey across five teams that mostly talk within their own walls, and the software inherits the same boundaries the organization has. The release breaks at the boundary between two teams, where the calls that need the whole picture don’t belong to anyone.

Put that prediction next to a real feature. I kept it deliberately small here, just to picture the shape; the real ones are bigger and messier.  

A customer sends across dozens of destinations, each with its own registration rules. Provisioning sets the customer up to send, sender registration gets each sender approved per destination. The hard cases raise questions neither team can answer alone: when a sender is fine in one country and refused in the next, does provisioning collect a fallback, does registration substitute one, or does the campaign ship partial?  

No owners means no decisions

Since there’s no owner, there is no decision.

Instead, each team codes to its own assumption and passes its own tests, and the assumptions only collide in some cases that cross between teams. The first customer with a mixed set of destinations goes live approved in some and silently refused in others. This is a fix that looks obvious at this size, but at real scale it’s dozens of these calls across five teams, and the someone who should make them is still no one. 

It starts when the date is set before the scope or target customer is clear. Then teams start building without knowing where to stop. One team works on an edge case for full GA, while another builds for customers who aren’t onboarded yet.

“Early release” becomes “the whole thing” slowly, one decision at a time. It stays invisible because each team is doing good work on its own. The drift only exists at the level nobody is watching, which is the whole end-to-end journey, or the big picture. A release that goes out with no defined scope, no chosen customer, and no one leading it pushes the risk onto whoever is downstream.

Cutting scope on purpose is different. You choose what to leave out and handle the rest manually, so the customer still gets value without needing the unfinished parts.

The case against shared ownership

Shared ownership across those teams is where the whole falls through. Everybody owns a piece, which really means no one owns the whole.

When multiple teams each hold a piece of a customer journey, someone has to lead the end-to-end release. This should ideally be one or two people who know the flow in real detail: which service does what, where the boundaries between teams are, what a real customer actually experiences from first call to final result.  

A steering committee can set priorities and handle escalations, but it can’t lead the release day to day. A manager who only sees team status reports can’t do that either. The details that decide the release depend on how the pieces fit together, and neither of them is close enough to manage that.

In practice, that leadership is coordination work, not a box on the chart. The owner learns the whole flow and keeps it in their head. They draw the reduced-scope line and publish it, so every team is working from the same picture of what “first version” means.  

They watch for symptoms of a team drifting, which can include hardening a GA edge case or generalizing too early in the process. They decide where “reduced scope” ends and “next phase” begins and call the release. Most orgs already have someone near this role. Often, that’s a product manager or a TPM. 

Try making one person responsible for the release end to end

Define the reduced scope and target customer before you set the date. Write it down. Give it one owner who understands the whole flow. And when the first customer hits a gap, fix it in the shared path so the next customer doesn’t run into it too.

The reason it doesn’t happen is that leading five teams end to end is hard, unglamorous management work, and in most organizations it isn’t any single manager’s job. Each manager runs one team and looks after that team’s part of the release. The coordination across teams is no one’s job.

Some organizations avoid this because leading the whole is already built into someone’s job, or the structure is flat enough that the whole stays visible. The teams aren’t weak and nobody is being lazy; the job that needs doing simply isn’t anyone’s job. The fix is to make one person responsible for the release end to end, and to give them the room to actually lead it. 

Sometimes, though, one person genuinely can’t lead the whole thing, however skilled they are. In a matrix organization, an agency where the client signs off every step, or a regulated field where the approval path is set from outside, the flow crosses boundaries a single coordinator can’t reach across. 

If your structure genuinely prevents one person from leading end to end, no release process will fix it, because the real constraint is how the organization is wired. The release is only where that constraint first becomes visible.