If Your Meeting Needs People From Five Teams, Something's Broken

One team owns the UI. Another owns the backend service. A third manages experimentation. Someone else handles audience distribution.

Before long there are five teams involved in delivering one idea. Everyone nods along as the work gets divided up. Then there’s usually a quiet realisation: This just became a very expensive meeting.

Not because the people are expensive, but because the system requires so many people to coordinate before anything can move forward.

What looks like a planning exercise is often really a sign that the flow of value is fragmented.

For years engineering organisations tried to solve this by creating cross-functional teams. Backend, frontend, QE. Sometimes design and product. It was a big improvement. But in many organisations it turned out to be only halfway to the goal.

The halfway version of cross-functional

Most “cross-functional” teams today are actually cross-functional within engineering only. They bring together different technical roles, but the team is still primarily responsible for building software.

Other parts of delivering value often sit elsewhere:

• marketing
• editorial
• audience teams
• experimentation and analytics

These groups collaborate with the team, but they’re not really part of the same system of work. So although the engineering team can technically ship code end-to-end, delivering value still depends on coordination across multiple groups.

Teams that own “everything”

Another pattern often appears alongside this. Teams are cross-functional, but their scope is extremely broad. A team responsible for an entire product or brand might touch:

• homepage features
• article pages
• subscriptions
• comments
• advertising

Instead of developing deep ownership in one area, the team ends up skimming across dozens of concerns. They can technically do everything, but rarely have the space to master anything.

Thinking about value as a river

One way to think about this is as a river. The river represents value flowing to a user. When the system works well, the water moves smoothly downstream. But along the way we often introduce obstacles:

• team boundaries
• ownership confusion
• duplicated systems
• multiple approvals
• unclear responsibilities

Each obstacle slows the flow. Sometimes the river even splits into channels that never quite reconnect. What looks like a team structure problem is often really a flow problem.

Value streams follow the river

A value stream is simply the path that value takes as it flows to a user. Instead of organising teams around technologies, brands, or departments, organisations identify the natural flows of value.

For example, a digital platform might have streams such as:

• Content Publishing
• Reader Experience
• Subscriptions
• Advertising
• Audience Growth

Each stream represents a continuous capability that contributes to how value reaches users. Teams aligned to these streams focus on improving one section of the river, rather than skimming across everything.

Example: a Reader Experience stream

A team aligned to the Reader Experience stream focuses on how users discover and consume content. Their work might include:

• homepage experiences
• article layout and presentation
• performance and load times
• recommendations and personalisation
• reading features like bookmarking or following topics

The team isn’t responsible for the entire product, and they’re not tied to a specific brand. Instead, they continuously improve the experience of reading itself.

Over time they develop deeper expertise in that space and can make meaningful improvements to how users interact with the product. And importantly, this stream often involves more than engineers.

Editorial, product, analytics, and audience teams may all contribute to improving this part of the user journey.

That’s when teams start to become truly cross-functional, aligned around a shared outcome rather than a departmental boundary.

What about multi-brand organisations?

Many organisations operate multiple brands or products, which often leads to a different structure:

• Brand A Team
• Brand B Team
• Brand C Team

Each team becomes responsible for everything within that brand. But over time it often leads to familiar problems: teams solving the same problems multiple times, inconsistent experiences across brands, duplicated systems, expertise spread thinly across teams.

Instead of building depth in one area, teams end up skimming across many domains.

Streams often cut across brands

When organisations start thinking in value streams, something interesting happens. Many streams naturally span multiple brands.

For example:

• a Reader Experience stream improving article pages across every brand
• a Subscriptions stream managing paywalls and billing across the platform
• a Content Publishing stream supporting editorial teams regardless of brand

The teams focus on improving a capability, while brands become different expressions of that capability. The streams improve the engine. The brands decide how that engine shows up to different audiences.

Where Team Topologies fits

Once value streams are identified, the ideas in Team Topologies help describe how teams interact. At the centre are stream-aligned teams that own part of the value flow.

Supporting teams — platform, enabling, and complicated subsystem teams — help remove obstacles and reduce cognitive load.

The goal isn’t to draw the perfect org chart. It’s to design teams so the river can flow more freely.

---

Cross-functional engineering teams were a big step forward. But many organisations stopped there.

They built teams capable of delivering software end-to-end, while the rest of the value chain remained scattered across the organisation.

Value streams push us one step further, aligning teams around the actual flow of value. Because improving delivery isn’t just about how work happens inside a team. It’s about removing the rocks that slow the river down.