Every team I walk into these days describes itself as cross-functional: Design, backend, frontend, Q&A, sometimes a data person, all sitting under one banner, one agile board, one set of OKRs. A dream team of star players! A self-sufficient unit that can ship without waiting on six other teams.
In practice however, I keep finding similar things once I look at how work actually moves inside these teams:
Design finishes a Figma file and hands it to frontend;
Frontend builds the screen and hands it to backend for the API contract;
Backend ships the endpoint and hands it back.
Everyone is in the same Slack channel, everyone attends the same standup, and the work still travels in one direction with almost no feedback flowing upstream. It’s a waterfall wearing a cross-functional badge.
This isn’t a discipline problem. It’s a structural one, and it shows up everywhere.
In smaller teams, the silo is informal: people sit near each other, at the same fixed flex desk distribution, so they assume that proximity equals collaboration. It doesn’t.
At larger scale, the same scenario gets dressed up in better tooling. Organizations adopt squads, tribes, and chapters (you may recognize the so-called “Spotify model”) to align ten or twenty teams around shared technical concerns. A thing companies do because everyone else does it, not because anyone checked what applies to their situation. It’s worth repeating: Spotify itself has been clear for over a decade that the 2012 paper describing their setup was descriptive, not prescriptive, and (more importantly) that they’ve since moved on from large parts of it.
Companies are still implementing a snapshot of one company’s internal documents from a decade ago as a doctrine.
The intent behind the adoption is usually clear: communication channels grow exponentially as you add people, so you need structures that contain that growth. What actually happens is that the chapter meetings about technology start to matter more than the conversations inside the team. Alignment on tech stack starts to outrank alignment on the actual problem the team tries to solve.
It is not an uncommon example for a chapter meeting to spend forty minutes on a caching strategy nobody on the actual product team had asked for, while the product team’s real blocker went untouched for another sprint.
The cost of this is hard to make visible. It shows up later as rework.
AI has made this worse in a way worth naming. When a developer, assisted by AI, can generate a working implementation from a vague ticket in twenty minutes, the temptation to skip the conversation and just build something is stronger than ever. The tools have gotten faster at executing the wrong shared understanding, not just the right one, because it doesn’t differentiate between them, it simply duplicates patterns that exist.
Are multi-disciplinary teams at fault? Not quite. Think about the alternative: dependency hell across silos. That is way worse. The actual problem is that most teams stopped at the adopting a structure. They never built the habits that make the multi-disciplinary team structure pay off. Having a designer and a backend developer on the same team is the starting point. The goals is a collaboration where a backend developer understands what the design is trying to achieve for the user, and a designer understands what the architecture can and can’t facilitate without hefty rework.
The single most impactful change I’ve seen teams make is moving the cross-disciplinary conversation to before the ticket is written. Most teams default to a kickoff that looks like a (waterfallesque) status update: design presents what they’ve made, engineering asks clarifying questions focused on the design. By the time engineering gets hands on with the change, the constraints have already been baked into the design, and pushback feels like friction (the age old battle between designer and developers) rather than collaboration.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.