Collaboration, the gears of a cross-functional team

A team once launched a feature that was visually polished, technically solid, and completely unusable. The interaction pattern confused users. The copy didn’t match the context. The accessibility wasn’t there. Nobody had done anything wrong in isolation. The designer designed. The developer built. The PM approved. But none of them had been in the room at the right moments to catch what the others couldn’t see.

That’s what siloed work produces: parts that work individually and a whole that doesn’t.

The relay race problem

Most cross-functional teams operate like a relay race. Product defines. Design designs. Engineering builds. QA tests. Each handoff is a moment where context gets lost and assumptions don’t get questioned.

The designer didn’t know the interaction they scoped would require three extra API calls and would feel sluggish on slower connections. The engineer didn’t know the layout decision had a rationale behind it that would make future changes complicated. The PM didn’t know either until the sprint review.

Agile ceremonies are supposed to prevent this. Stand-ups, refinements, retrospectives: they’re the structural mechanisms for keeping a team in sync. But they only work if the people in the room are actually talking, not just reporting status. A stand-up where everyone says “working on my ticket, no blockers” and moves on is a relay race with extra steps.

The difference between a cross-functional team that works and one that doesn’t is usually whether designers and engineers are talking to each other before the designs are finalized, not after. Whether the PM explains the “why” behind a feature, not just the spec. Whether the person writing the copy is involved early enough to influence the information architecture, not just fill in labels at the end.

What actually gets in the way

Two things consistently break cross-functional collaboration: different timelines and different sources of truth.

When design is three sprints ahead of engineering, engineers are constantly implementing decisions that were made without them. By the time they spot a problem in the design, it’s “already approved” and reopening it feels like going backwards. The earlier engineers are in design conversations, even just 20 minutes to review a prototype, the fewer of those problems appear downstream.

Different sources of truth is subtler. When the PM’s understanding of what a feature does differs from the engineer’s implementation and the designer’s vision, you don’t usually find out until review. That’s when everyone realizes they were building slightly different things. Shared documents, recorded decisions, and explicit alignment checkpoints aren’t bureaucracy. They’re insurance against discovering the problem too late.

When leadership pressure overrides the process

I watched a team skip accessibility review and launch without sufficient UX input because an executive set a deadline that wasn’t negotiable. Nobody pushed back. The feature shipped with compliance gaps and usability problems that took three more sprints to fix, at considerably more cost than getting it right the first time would have.

That pattern is common. Leadership shortens a timeline, the team absorbs the impact by cutting the parts that feel optional but aren’t, and the cost shows up later in ways that are harder to attribute directly to the decision.

Part of the EM job is managing up when this happens, explaining the actual cost of skipping the collaboration steps, not as a complaint about process but as a business case. “If we cut UX review, we’ll likely spend X days fixing usability issues after launch” is a more useful conversation than “we need more time.” It frames the trade-off in terms leadership can evaluate.

The teams that sustain good cross-functional collaboration do it because someone made sure it survived the moments when speed felt more urgent than quality. That protection is most of the job.