Managing Multidisciplinary Teams, Why Most Cross-Functional Friction Is Structural

TL;DR — Most cross-functional friction looks like personality conflict but is actually structural / Team Topologies gives you four clear team patterns to choose from / fix the wiring first, the relationships will mostly fix themselves.

A few years into managing my first cross-functional team, I had a designer and an engineer who couldn’t be in the same meeting without sniping at each other. Classic personality clash, I thought. I brought in a coach. We did 1:1s. We did expectations resets. Nothing stuck. Then I redrew the team boundaries — separated their work streams so they each had clean ownership of their part of the problem — and within a month they were collaborating fine. The conflict wasn’t them. It was the wiring.

That experience reframed how I think about cross-functional teams. The default assumption is that friction is interpersonal, so we apply interpersonal tools — feedback, coaching, retros. Sometimes that’s right. More often, the structure is forcing people into ambiguous handoffs, unclear ownership, or competing incentives, and no amount of interpersonal skill will fix a bad wiring diagram.

This post is about diagnosing those structural problems and fixing them. I’ll lean heavily on Skelton and Pais’s Team Topologies because it’s the most useful framework I’ve found for naming what’s going on. This is the fourth post in my December leadership series — earlier ones covered the tech lead transition and consultative discovery.

The Diagnostic Question

Before changing anything about a team, the question to sit with is: what is this team’s promise to the rest of the organization?

If you can’t answer that in one sentence, you’ve found the problem. Teams without a clear promise become political mush. Every quarter is a negotiation about scope, every project is a fresh debate about ownership, and every cross-team interaction is a low-grade renegotiation of who’s responsible for what.

Good team promises sound like:

• “We own the checkout experience end-to-end, from cart to confirmation.”
• “We provide self-service infrastructure to product teams, so they don’t have to think about Kubernetes.”
• “We are the experts on payments and we help product teams integrate correctly.”

Bad team promises sound like:

• “We work on important strategic initiatives.”
• “We support multiple product teams.”
• “We do design.”

The bad versions aren’t promises. They’re descriptions of activity. A team with no promise can be working extremely hard and still fail to deliver value, because nothing they do is legibly theirs.

The Four Team Types

Team Topologies names four useful patterns. They’re not exhaustive but they’re more than enough to cover most situations.

Stream-Aligned Team

A team aligned to a single value stream — a product, a customer journey, a business capability. It owns its work end-to-end and ships independently. Most product engineering teams should be stream-aligned, but in practice many aren’t, because dependencies on platform, design systems, security, or data leak in and break the stream.

When it works: stream-aligned teams feel fast. PRs merge, things ship, the team can explain what they did this quarter without consulting a Jira filter.

When it doesn’t: the team is “stream-aligned” on paper but blocked weekly by some other team. The promise is real, the autonomy isn’t.

Platform Team

A team that provides internal services as a product to other teams. Examples: developer experience, CI/CD platform, internal API gateway, observability stack. The key word is product — a platform team that treats its outputs as projects rather than products tends to ship things and then move on, leaving stream-aligned teams holding broken tools.

The hardest thing about running a platform team is fighting the urge to centralize control. The right posture is “we make the paved road so attractive that you choose it,” not “you must use this.” If you have to mandate adoption, your platform isn’t a product, it’s a tax.

Enabling Team

A team of specialists who embed temporarily with stream-aligned teams to lift their capability — security, performance, accessibility, ML. Enabling teams should not own production systems. Their job is to make other teams capable, then leave. If they linger, they become a bottleneck and a single point of expertise that the rest of the org never develops.

Most failures here come from misunderstanding the time-bound nature of the engagement. An enabling team is a temporary consulting relationship, not a permanent dependency. Mark it as such, write the exit criteria into the engagement, and stick to it.

Complicated-Subsystem Team

A team that owns a system requiring deep specialist knowledge — payments, billing, search relevance, ML infrastructure. The point of carving it out is that the cognitive load is too high to spread across stream-aligned teams.

The risk: the complicated subsystem becomes a black box that nobody else in the org understands, and the team becomes both indispensable and unreviewable. Mitigation is documentation and consultation rituals — the complicated-subsystem team should publish RFCs and design docs that others can read, and should hold office hours so the rest of the org can ask questions without filing tickets.

Interaction Modes Matter More Than You Think

Team Topologies also names three interaction modes — collaboration, X-as-a-service, and facilitating — and arguments about these are where most cross-team friction actually lives.

• Collaboration is two teams working together on a shared problem with overlapping ownership. High bandwidth, high cost. Useful for genuinely novel work that nobody fully owns yet. Bad as a default — sustained collaboration between teams usually means you should have merged them or carved them apart more cleanly.
• X-as-a-service is one team consuming another team’s output through a stable interface — an API, a UI library, a runtime. Low bandwidth, low cost. The right default for most production dependencies.
• Facilitating is one team helping another team learn or unblock — the enabling-team pattern. Time-bound, knowledge-transfer focused.

Most cross-functional friction comes from teams being in collaboration mode when they should be in X-as-a-service mode. Designers and engineers in collaboration on every ticket is exhausting and slow. Designers shipping a design system as a service, with engineers consuming components through a clean interface, is sustainable. Same people, same disciplines, completely different friction profile.

A Worked Example

Let me make this concrete with a composite case from a few past projects.

A growth team has six engineers, two designers, one PM, and a part-time data scientist. They’re tasked with “improving onboarding conversion.” Every retro surfaces the same complaints: designers feel rushed, engineers feel like specs change midway through sprints, the PM feels like nothing ships on time, the data scientist barely knows what the team is working on this week.

Diagnostically, what’s going on?

• The team is nominally stream-aligned (onboarding) but the stream isn’t well-defined. Is it the marketing page? The signup flow? The first-week activation? Different team members are optimizing different metrics.
• The designers are in collaboration mode with engineers on every ticket, which means design becomes the bottleneck because there are only two of them.
• The data scientist is in facilitating mode but no one has defined the exit criteria, so they oscillate between embedded and ignored.
• The PM is acting as the integration point for all of this, which makes them a single point of failure.

Restructuring moves that work:

• Tighten the team’s promise to one specific funnel stage (e.g., “we own signup to activation, weeks 1 to 4”).
• Move design from per-ticket collaboration to a small design-system contribution, plus discovery-phase collaboration only.
• Time-box the data scientist’s engagement and define what they’re handing back.
• Spread integration work across the team rather than parking it with the PM.

None of this requires firing anyone, hiring anyone, or running another offsite. It requires drawing the team boundary and interaction modes more carefully.

A Lightweight Topology Doc

Whenever I’m setting up or reshaping a multidisciplinary team, I write a short topology doc. It lives in the team wiki, gets reviewed quarterly, and is the first thing I share with anyone joining.

# Team Topology — <Team Name>

## Promise
One-sentence description of what this team delivers to the rest of the org.

## Team Type
Stream-aligned / Platform / Enabling / Complicated-subsystem.
Why this type and not the others.

## Owned Surface
- Systems, services, repos this team owns end-to-end:
- Systems this team contributes to but does not own:
- Systems this team explicitly does NOT touch:

## Interaction Modes
- Team X: collaboration (until <date>, then re-evaluate)
- Team Y: X-as-a-service via <API/library/interface>
- Team Z: facilitating (specific engagement, ends <date>)

## On-Call & Operational Ownership
- Who pages who, for what
- Hours, escalation, runbook locations

## Decision Rights
- Decisions this team makes unilaterally:
- Decisions this team makes with input from <stakeholders>:
- Decisions this team escalates to <leadership>:

## Disciplines Involved
- Engineers, designers, PM, data, ops — and what each person's "lane" is
  on this team specifically.

## Review Cadence
- This doc is reviewed every <quarter / six months>.
- Last reviewed: <date>
- Next review: <date>

The doc is short on purpose. If it grows beyond two pages, the team’s scope is probably too broad and needs to be split. The act of writing it is what does most of the work — disagreements about what to put in it are disagreements about the team’s identity, and surfacing those early is the whole point.

Common Pitfalls

Treating structural problems as interpersonal ones. If the same conflict shows up across multiple pairs of people, it’s the structure. Stop coaching individuals and redraw the boundary.

Confusing matrix reporting with cross-functional work. Matrix structures (people reporting to discipline managers, working on cross-discipline teams) can work, but they require clear decision rights about who chooses scope vs. who chooses execution. Most matrices are ambiguous on this and produce learned helplessness.

Over-collaborating. Sustained collaboration between teams is expensive. If two teams are constantly in collaboration mode, ask whether they should merge, or whether one should provide a service to the other.

Letting platform teams ship projects, not products. A platform team that ships a tool and walks away is functionally indistinguishable from an external vendor that doesn’t return your emails. Platform output is a product with a roadmap, a feedback loop, and a deprecation policy.

Forgetting that team design is also product design. The first product decision you make is who’s on the team and what they own. Get that wrong and no amount of process will save you. Get it right and many “process problems” simply disappear.

Wrapping Up

Cross-functional teams are hard, but they’re hard in legible ways. The four-team-type framework gives you a vocabulary to name what’s going on, and the interaction modes give you a way to name what’s expensive about how teams currently relate to each other. Before reaching for interpersonal interventions, reach for a whiteboard and redraw the wiring.

Next post: RFCs and ADRs as leadership tools — why writing things down is the most underrated leverage move in technical leadership.